perm filename CLOBOR.MSG[COM,LSP]2 blob
sn#780203 filedate 1984-12-23 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 Introduction
C00006 ENDMK
C⊗;
Introduction
Welcome to the Common Lisp Object-Oriented Programming Subgroup.
In order to mail to this group, send to the address:
CL-Object-Oriented-Programming@su-ai.arpa
Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:
CLOBOR.MSG[COM,LSP]
You can read this file or FTP it away without logging in to SAIL.
To communicate with the moderator, send to the address:
CL-Object-Oriented-Programming-request@su-ai.arpa
Here is a list of the people who are currently on the mailing list:
Person Affiliation Net Address
Richard Greenblatt LMI "rg%oz"@mc
Scott Fahlman CMU fahlman@cmuc
Eric Schoen Stanford schoen@sumex
Gordon Novak Univ. of Texas novak@utexas-20
Kent Pitman MIT kmp@mc
Dick Gabriel Stanford/Lucid rpg@sail
David Wile ISI Wile@ISI-VAXA
Martin Griss HP griss.hplabs@csnet-relay (I hope)
Walter VanRoggen DEC wvanroggen@dec-marlboro
Richard Zippel MIT rz@mc
Dan Oldman Data General not established
Larry Stabile Apollo not established
Bob Kessler Univ. of Utah kessler@utah-20
Steve Krueger TI krueger.ti-csl@csnet-relay
Carl Hewitt MIT hewitt-common-objects@mc
Alan Snyder HP snyder.hplabs@csnet-relay
Jerry Barber Gold Hill jerryb@mc
Bob Kerns Symbolics rwk@mc
Don Allen BBN allen@bbnf
David Moon Symbolics moon@scrc-stonybrook
Glenn Burke MIT GSB@mc
Tom Bylander Ohio State bylander@rutgers
Richard Soley MIT Soley@mc
Dan Weinreb Symbolics DLW@scrc-stonybrook
Guy Steele Tartan steele@tl-20a
Jim Meehan Cognitive Sys. meehan@yale
Chris Reisbeck Yale riesbeck@yale
The first order of business is for each of us to ask people we know who may
be interested in this subgroup if they would like to be added to this list.
Next, we ought to consider who might wish to be the chairman of this subgroup.
Before this happens, I think we ought to wait until the list is more nearly
complete. For example, there are no representatives of Xerox, and I think we
agree that LOOPS should be studied before we make any decisions.
∂23-Sep-84 1607 RPG Introduction
To: cl-object-oriented-programming@SU-AI.ARPA
Welcome to the Common Lisp Object-Oriented Programming Subgroup.
In order to mail to this group, send to the address:
CL-Object-Oriented-Programming@su-ai.arpa
Capitalization is not necessary, and if you are directly on the ARPANET,
you can nickname SU-AI.ARPA as SAIL. An archive of messages is kept on
SAIL in the file:
CLOBOR.MSG[COM,LSP]
You can read this file or FTP it away without logging in to SAIL.
To communicate with the moderator, send to the address:
CL-Object-Oriented-Programming-request@su-ai.arpa
Here is a list of the people who are currently on the mailing list:
Person Affiliation Net Address
Richard Greenblatt LMI "rg%oz"@mc
Scott Fahlman CMU fahlman@cmuc
Eric Schoen Stanford schoen@sumex
Gordon Novak Univ. of Texas novak@utexas-20
Kent Pitman MIT kmp@mc
Dick Gabriel Stanford/Lucid rpg@sail
David Wile ISI Wile@ISI-VAXA
Martin Griss HP griss.hplabs@csnet-relay (I hope)
Walter VanRoggen DEC wvanroggen@dec-marlboro
Richard Zippel MIT rz@mc
Dan Oldman Data General not established
Larry Stabile Apollo not established
Bob Kessler Univ. of Utah kessler@utah-20
Steve Krueger TI krueger.ti-csl@csnet-relay
Carl Hewitt MIT hewitt-common-objects@mc
Alan Snyder HP snyder.hplabs@csnet-relay
Jerry Barber Gold Hill jerryb@mc
Bob Kerns Symbolics rwk@mc
Don Allen BBN allen@bbnf
David Moon Symbolics moon@scrc-stonybrook
Glenn Burke MIT GSB@mc
Tom Bylander Ohio State bylander@rutgers
Richard Soley MIT Soley@mc
Dan Weinreb Symbolics DLW@scrc-stonybrook
Guy Steele Tartan steele@tl-20a
Jim Meehan Cognitive Sys. meehan@yale
Chris Reisbeck Yale riesbeck@yale
The first order of business is for each of us to ask people we know who may
be interested in this subgroup if they would like to be added to this list.
Next, we ought to consider who might wish to be the chairman of this subgroup.
Before this happens, I think we ought to wait until the list is more nearly
complete. For example, there are no representatives of Xerox, and I think we
agree that LOOPS should be studied before we make any decisions.
∂27-Sep-84 0737 DUGGAN@UTAH-20.ARPA Please add me ty your group
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 27 Sep 84 07:37:16 PDT
Date: Thu 27 Sep 84 08:39:01-MDT
From: Jerry Duggan <duggan@UTAH-20.ARPA>
Subject: Please add me ty your group
To: cl-object-oriented-programming@SU-AI.ARPA, cl-subsets@SU-AI.ARPA
I work with Bob Kessler at the University of Utah.
Jerry Duggan
-------
∂02-Oct-84 1310 RPG Chairman
To: cl-object-oriented-programming@SU-AI.ARPA
Now that we've basically got most everyone who is interested on the mailing
list, let's pick a chairman. I suggest that people volunteer for chairman.
The duties are to keep the discussion going, to gather proposals and review
them, and to otherwise administer the needs of the mailing list. I will
retain the duties of maintaining the list itself and the archives, but
otherwise the chairman will be running the show.
Any takers?
-rpg-
∂11-Oct-84 1024 Stefik.pa@Xerox.ARPA Re: Introduction
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 11 Oct 84 10:16:52 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 11 OCT 84 10:14:39 PDT
Date: 11 Oct 84 10:06 PDT
From: Stefik.pa@XEROX.ARPA
Subject: Re: Introduction
In-reply-to: Dick Gabriel <RPG@SU-AI.ARPA>'s message of 23 Sep 84 16:07
PDT
To: RPG@SU-AI.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA
Richard -- I would also like to join the discussion. Mark
∂13-Oct-84 1439 RPG Chairman
To: cl-object-oriented-programming@SU-AI.ARPA
Jonathon Rees has been nominated as chairman of the Object-oriented
subgroup. If he is willing, and no one else volunteers, he will
become chairman. Please respond by October 24. At the end of this month
I want to see some ideas and proposals coming in on this mailing list.
-rpg-
∂24-Oct-84 1926 HANDERSON@CMU-CS-C.ARPA Project description
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Oct 84 19:26:37 PDT
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Wed 24 Oct 84 22:26:58-EDT
Date: Wed, 24 Oct 1984 22:26 EDT
Message-ID: <HANDERSON.12058126458.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To: cl-object-oriented-programming@SU-AI.ARPA
Subject: Project description
In-reply-to: Msg of 13 Oct 1984 17:39-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
We might as well start by saying what various projects are in the works.
I've heard of a Loops project going on somewhere - maybe somebody
involved in that can say how it's going.
I'm currently working with Moon to try to develop a (hopefully small)
kernel to implement Flavors in. This might also be good for applications
that construct functions that call component operations ("combined
methods" they're called) and has the Flavor-like notion of instance
variables (i.e. those with the same name are the same). We're currently
trying to use abstraction to come up with something neat and clean.
I will be pushing for a notion of methods that puts the defmethod in the
lexical environment (like defun) and the instance variables with the
lexical variables (allowing you to close over them). I have a prototype
that does this using a form of symbol macros, but this could be added
specially. Also, if instance variables are like lexical variables, then
if the instance variables of the flavor changes, the method can become
invalid [as if (let ((a 3)) a) suddenly became just a]. I will push for
a kernel that can throw out methods if it thinks it needs to (as long as
it notifies the user). The rest is just trying to keep the kernel
clean.
∂27-Oct-84 2145 RPG Hello folks
To: cl-object-oriented-programming@SU-AI.ARPA
We now have a chairman of the object-oriented programming subgroup:
Ken Kahn of Xerox Parc. I think he will make an excellent chairman
because he has extensive experience with both the MacLisp/ZetaLisp
style of doing things, Prolog, and LOOPS and InterLisp. For your information
I am including the current members of the mailing list.
I will now let Ken Kahn take over responsibility for the discussion.
David Matthews HP "hpfclp!objects%hplabs"@csnet-relay
Ken Sinclair LMI "khs%mit-oz"@mit-mc
Neil Goldman ISI GOLDMAN@ISI
Mark Stefik Xerox Stefik.pa@XEROX
John Foderaro Berkeley jkf@ucbmike.arpa
Jon Sticklen Ohio State Sticklen@rutgers
Danny Bobrow Xerox bobrow.pa@xerox
Jonathon Rees MIT jar@mc
Howard Cannon Symbolics "hic%scrc"@mc
Jerry Duggan Univ of Utah duggan@utah-20
Dave Dyer Symbolics ddyer@isib
Christopher Stacy MIT cstacy@mc
Richard Greenblatt LMI "rg%oz"@mc
Scott Fahlman CMU fahlman@cmuc
Eric Schoen Stanford schoen@sumex
Gordon Novak Univ. of Texas novak@utexas-20
Kent Pitman MIT kmp@mc
Steve Handerson CMU handerson@cmuc
Dick Gabriel Stanford/Lucid rpg@sail
David Wile ISI Wile@ISI-VAXA
Martin Griss HP griss.hplabs@csnet-relay (I hope)
Walter VanRoggen DEC wvanroggen@dec-marlboro
Richard Zippel MIT rz@mc
Dan Oldman Data General not established
Larry Stabile Apollo not established
Bob Kessler Univ. of Utah kessler@utah-20
Steve Krueger TI krueger.ti-csl@csnet-relay
Carl Hewitt MIT hewitt-common-objects@mc
Alan Snyder HP snyder.hplabs@csnet-relay
Jerry Barber Gold Hill jerryb@mc
Bob Kerns Symbolics rwk@mc
Don Allen BBN allen@bbnf
David Moon Symbolics moon@scrc-stonybrook
Glenn Burke MIT GSB@mc
Tom Bylander Ohio State bylander@rutgers
Richard Soley MIT Soley@mc
Dan Weinreb Symbolics DLW@scrc-stonybrook
Guy Steele Tartan steele@tl-20a
Jim Meehan Cognitive Sys. meehan@yale
Chris Reisbeck Yale riesbeck@yale
Ron Fischer Rutgers fischer@rutgers
Jonl White Xerox jonl@xerox
Neal Feinberg Symbolics feinberg@scrc-stony-brook
Ken Kahn Xerox kahn@xerox
∂30-Oct-84 1128 Kahn.pa@Xerox.ARPA Issues in object oriented programming in Common Lisp
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 30 Oct 84 11:27:55 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 30 OCT 84 11:25:04 PST
Date: 30 Oct 84 11:25 PST
From: Kahn.pa@XEROX.ARPA
Subject: Issues in object oriented programming in Common Lisp
To: cl-object-oriented-programming@SU-AI.ARPA
cc: Kahn.pa@XEROX.ARPA, Henry@MIT-MC.ARPA, Mittal.pa@XEROX.ARPA
To different people object oriented programming in Common Lisp means
very different things. I think the first thing we should do is discuss
what people want done. I assume most people feel the tension between
some kind of standard (that will help portability, provide an
opportunity to clean up and rationalize existing systems, promote
communication of ideas, etc.) and the dangers of premature
standardization.
Some of the questions going through my head are:
(1) Is there some small kernel for objects that is adequate for building
multiple inheritance, method specialization, method demons, and whatever
else that people want?
(2) Where do most people stand on some the rather basic issues of
object-oriented systems such as
(a) Should there be a distinction between classes and instances? I.e.
should one be able to add methods to instances?
(b) How private should instance variables be? Need one send messages
to access them? To access other's instance variables? What should be
encouraged vs. enforced?
(c) Should message passing be based upon selectors or more general
pattern matching?
(d) Should there be class variables?
(e) What is a reasonable set of initial classes or flavors? What
methods should they have?
(f) How should "self" be treated?
(g) How should multiple inheritence work?
(h) Should there be meta classes?
(i) How should objects interface with Lisp? What should happen if a
Lisp primitive is applied to an object? Should SETF etc. work on
message sending? Should objects be functional objects ala ZetaLisp?
(j) Are methods themselves objects? Are classes? ...
(k) Should the system support the notion of protocols that are
collections of behaviors?
(3) Terminology. Maybe before doing much else we should come to some
consensus about what terminology to use. Do people think that "flavor"
is better than "class"? Do people like "subflavor", "abstract flavor",
etc. ? There seems to be at least three different ways of talking
about objects the Flavors way, the SmallTalk/Loops way, and Hewitt's
actors. What do people prefer?
(4) Syntax. What should a method definition look like? What about a
message transmission? A flavor definition?
I'm sure that there are a lot more issues that I'm just not thinking
of. So feel free to add your own.
Instead of 40 people trying to discuss 20 issues simoultaneously, I
propose that we serialize the discussion. To get things rolling I'll
pick one of the issues above, describe the alternatives, and try to
bring out the arguments pro and con.
(2) (b) Instance variables.
There are several ways in which instance variables are treated in
different object-oriented programming languages. Flavors takes the
position that the instance variables of "self" can be accessed and set
just as ordinary Lisp variables within a method. Instance variables of
others are accessed or set via message passing. To make this easier the
appropriate methods can be generated automatically. In a language I did
several years ago called Director all instance variable access and
update were done by message sending. In Loops one refers to instance
variables by function call. There are macros so that this is as consise
as possible. Lets call these instance variable schemes "Lisp variables
for self", "message passing", and "function call".
Lisp variables for self: Consise and potentially very efficient when
refering to self's instance variables; clean, modular, relatively
inefficient and verbose when refering to others, nearly impossible to
implement in Lisp (one must change the kernel to treat specially
variables that it recognizes are instance variables)
Message passing: Very modular, verbose, difficult to optimize, easy to
implement active values (demons on variable access and update) by method
demons or specialization, different name space for Lisp variables and
instance variables.
Function call: Easy to abuse (e.g. depend upon the internal
representation of other objects), easy to implement active values
(though via a seperate mechanism from method demons), different name
space for Lisp variables and instance variables.
One can make arguments about the arguments: A different name space is
good because it makes visually clear what is Lisp and what is object.
Modularity is important to maintain the ideal that an object is defined
behaviourally and its internal representation is hidden to the world.
Active values are very useful. One needs less mechanism if active
values can be supported by method specialization (demons). Etc.
Don't vote on these issues, instead add your own arguments.
I know that various groups have a lot invested in existing
object-oriented systems in Lisp (Flavors, Loops, KEE, ...). Perhaps its
too late to re-think some of these fundamental issues. I see several
possible outcomes from this Common Lisp subgroup's discussions. Perhaps
a new language will be designed, perhaps some common ground will be
identified, perhaps some existing sublanguage will be accepted by the
community as a standard, perhaps we'll come to understand the issues
better, perhaps nothing will happen. Its up to us, so please
participate.
Send in your 2 cents worth.
∂30-Oct-84 1545 HANDERSON@CMU-CS-C.ARPA Different systems, variables
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 30 Oct 84 15:45:28 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Tue 30 Oct 84 18:45:18-EST
Date: Tue, 30 Oct 1984 18:45 EST
Message-ID: <HANDERSON.12059669889.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To: cl-object-oriented-programming@SU-AI.ARPA
Subject: Different systems, variables
In-reply-to: Msg of 28 Oct 1984 00:45-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
Ken,
My own impression is that nobody knows how to do object oriented programming
(multiple inheritance in particular) "right," if there is indeed a right way;
instead, there are just a bunch of different ways of dealing with similar
problems. I would favor working backwards from existing systems- that would
give those of us familiar with only one system a chance to learn about others.
We might be able to come up with some commonalities, but I doubt they would
mean much in and of themselves.
Flavors people want instance variables to look like variables; this pretty much
requires that they act like them with respect to locality. If the semantics of
a method syntax depend on other than the target Flavor, changing those might
require many methods to be recompiled - painful, and currently impossible for
methods that have closed over something. Tagging the references with @! or
something lets the system nonambiguously associate references with the
operation, which it can then use in whatever way it wishes.
I'm partial to the "lisp variables for self", since it leads to an efficient
representation. It was difficult to implement, but not impossible; Symbolics
and I do it two different ways. I also think active values could be added to
Flavors - it's just a question of working out the specifics of a proposal. [If
someone familiar with these is interested in working out a proposal, I'd be
willing to put some time into it.]
I believe that one of the whole points of object-oriented programming is that
an object (and no one else) is responsible for its own integrity (behavioural).
Some instance variables might represent individual pieces of state; others
might be related in some complex way. Those that are related probably want to
be private- not accessible from anything but the class itself. If Flavors had
a :private-instance-variables option that would disallow inheriting those
instance variables, that would cover it.
-- Steve
∂31-Oct-84 0920 DDYER@USC-ISIB.ARPA Instance variables
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 31 Oct 84 09:20:47 PST
Date: 31 Oct 1984 09:17:08 PST
Subject: Instance variables
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-object-oriented-programming@SU-AI.ARPA
I also strongly favor the proposal that instance variables of
self be accessed as variables. I like it because they look
like variables, so you can know there is no funny business
going on when you get or set one.
Active values ought to be implemented as message protocols rather
than as instance variables with hidden behavior.
:PRIVATE-INSTANCE-VARIABLES ought to be available, and maybe
should be the default for instance variables unless they are
:GETTABLE or :SETTABLE.
-------
∂31-Oct-84 0948 DDYER@USC-ISIB.ARPA Fundamental Flavors
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 31 Oct 84 09:47:55 PST
Date: 31 Oct 1984 09:45:46 PST
Subject: Fundamental Flavors
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: cl-object-oriented-programming@SU-AI.ARPA
I strongly agree with the statement that no one knows how to
do multiple inheritence "right". There is no one "right"
way. If CL-objects expect to gain adherents, they will have
to accomodate many different styles, on this and other issues
of fundamental design.
What should really be specified is a basic architecture for
message passing, method definition, flavor definition, and
local storage, in which it is possible to define symbolics'
current flavors as a special case.
To be a little more specific;
The underlying machinery has to deal efficiently with
two principal problems; Locating the correct method
to invoke in a message pass, and locating the correct
instance variable to use for local variable references.
Except that it makes no provision for class variables,
I would propose that Symbolics' primitives for these
are adequately robust and effecient, and so can serve
as a starting point for the "primitives" discussion.
The algorithms which (at "flavor construction" time)
determine which methods will be found, and which instance
variables will be accessed by these effecient primitives,
should be modifiable rather than wired in. The obvious
way to do this is to make them methods of a flavor.
We would predefine a "really basic flavor constructor"
flavor, which would itself allow no daemons or inheretance,
but which would have methods to construct flavors
of the more complex varieties, which would in turn
be used to construct the instances we ordinarily use.
-------
∂31-Oct-84 1112 STICKLEN@RUTGERS.ARPA Re: Instance variables
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 31 Oct 84 11:11:51 PST
Date: 31 Oct 84 14:10:33 EST
From: Jon Sticklen <STICKLEN@RUTGERS.ARPA>
Subject: Re: Instance variables
To: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: Message from "Dave Dyer <DDYER@USC-ISIB.ARPA>" of 31 Oct 84 12:17:08 EST
is seems as if dave is confusing two issues:
1) whether or not IVs of self should be references as
simple variables
2) how active values should be implemented
suppose there were no AVs (or that dave's suggestion for AVs was
adopted). then there would be no "funny business" whether we accessed
an IV as a variable or by a function.
i'll save my coments on AVs until that discussion comes up.
not being familiar with FLAVORS, maybe someone could fill me in on
a base level: by going with referencing IVs of self as variables, isn't
the potential present of having a local var in a method with the same
name as a local IV? in FLAVORS, how is the name conflict problem
resolved?
---jon---
-------
∂31-Oct-84 1300 HANDERSON@CMU-CS-C.ARPA Instance variables
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 31 Oct 84 13:00:01 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Wed 31 Oct 84 15:59:09-EST
Date: Wed, 31 Oct 1984 15:58 EST
Message-ID: <HANDERSON.12059901710.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To: Jon Sticklen <STICKLEN@RUTGERS.ARPA>
Cc: cl-object-oriented-programming@SU-AI.ARPA
Subject: Instance variables
In-reply-to: Msg of 31 Oct 1984 14:10-EST from Jon Sticklen <STICKLEN at RUTGERS.ARPA>
The way to think of it is that the defmethod form wraps the method code with
something that "binds" the instance variables. If you bind something of the
same name, it shadows the instance-variable binding, as always. I've probably
said this too many times already, but it is my strong opinion and belief that
instance variables are naturally lexical (accessible only inside methods). If
so, I see no reason why they can't act just like Common Lisp lexical variables
and get closed over, etc. The result is very Common Lispy.
An illustration of closure:
(Defflavor my-flavor (a b) () :settable-instance-variables)
(defmethod (my-flavor :closure) ()
#'(lambda () a))
(funcall (send (make-instance 'my-flavor) :closure)) --> 3.
If this is not the case, the semantics of that reference have changed, probably
from being an instance variable to being something else. This is gross and
confusing.
-- Steve
∂31-Oct-84 1431 Kahn.pa@Xerox.ARPA Re: Instance variables
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 31 Oct 84 14:30:10 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 31 OCT 84 14:20:44 PST
Date: 31 Oct 84 14:17 PST
From: Kahn.pa@XEROX.ARPA
Subject: Re: Instance variables
In-reply-to: Steven <Handerson@CMU-CS-C.ARPA>'s message of Wed, 31 Oct
84 15:58 EST
To: Handerson@CMU-CS-C.ARPA
cc: STICKLEN@RUTGERS.ARPA, cl-object-oriented-programming@SU-AI.ARPA
I think you left out a 3 somewhere but I see the point.
I like the notion of thinking of a DEFMETHOD as something that expands
to a giant LET binding the instance variables to their values. The
problem then is with SETQ and the like.
Flavors sort of takes the view that an object is a functional closure
and that DEFMETHOD "edits" the definition of the function.
The reason I brought up active values at the same time as instance
variables is that they depend upon how instance variables are treated.
A message protocol can capture active values but it requires that
messages always be sent to access and update instance variables even
those of "self".
What I would like (and I think many would) is a message passing
semantics for access and update of instance variables with the
consiseness and efficiency of Flavors. Perhaps they are not
incompatible (I can imagine a compiler that compiles
(setq foo x) inside a method where foo is an instance variable to
something like (send self ':set-foo x). But could this be made
efficient? And is it really desirable to have something that looks like
a setq really be a send?). Perhaps compromises are necessary.
I like the idea of private instance variables. What is a little odd
about them is that they prevent methods of subflavors from seeing or
changing certain instance variables even though they are instance
variables of the instances of those subflavors.
Or was something else being proposed?
∂31-Oct-84 1441 AS%hp-hulk.csnet@csnet-relay.arpa Goals and Major Design Principles
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 31 Oct 84 14:40:32 PST
Received: from hplabs by csnet-relay.csnet id ah01171; 31 Oct 84 17:30 EST
Received: by HP-VENUS id AA23331; Wed, 31 Oct 84 12:49:50 pst
Message-Id: <8410312049.AA23331@HP-VENUS>
Date: 31 Oct 1984 1250-PST
From: AS%hplabs.csnet@csnet-relay.arpa
Subject: Goals and Major Design Principles
To: cl-object-oriented-programming%su-ai.arpa@csnet-relay.arpa
Source-Info: From (or Sender) name not authenticated.
Rather than immediately getting bogged down in technical design details
like how instance variables are accessed, I think we should try to
reach agreement on the goals of this effort and major design principles.
Here are some issues that I think are important:
* Hooks vs. Subset
One strategy that has been frequently mentioned is to define a collection of
primitive hooks upon which various objects systems can be implemented. From
the designers point of view, this is a wonderful idea, as it allows each
designer to do his own thing while we delay making any decisions. However,
this strategy fails to satisfy the need of Common Lisp USERS for a standard
definition they can USE to write code. So, while I support the (possibly
unrealistic) idea of a standard implementation base for objects, I think it is
more important that we attempt to come up with a usable "common subset" (in the
Common Lisp tradition) that is agreeable to the largest number of people.
* Start Simple
Because of the number of technical issues where substantial disagreement
appears to exist, we may have to restrict our definition severely to reach
agreement in a reasonable period of time. Given a choice between a severely
restricted definition (a "common subset") that appears soon versus a complete
and widely endorsed design that takes years to hammer out, I would recommend
the former as the more valuable. Certainly, it is easier to add new features
later than to change or remove features once they get into the definition.
* Multiple Objects Systems
The strategy of providing standard primitive hooks allows for the possibility
of supporting multiple coexisting objects systems. While there is merit in
this idea, I think our primary goal should be the definition of a single,
standard system.
* Efficiency
The Common Lisp objects system should be chosen to be efficient, particularly
on stock hardware, and usable on "small" machines. The efficiency goal argues
against including nonessential features in the standard that penalize all
message passing, regardless of whether the feature is used or not. (For
example, some features may require additional "hidden" arguments to method
functions.) The "small" machine goal argues against definitions that require
large run-time (as opposed to compile-time) data structures or on-the-fly
compilation. For example, one must be careful not to promise too much support
for incremental redefinition. A development system can always provide more
support than the definition requires.
* Avoid Exposing Implementation Details
To allow the most freedom to the implementor, and to allow future extensions
to the language, the objects system should avoid exposing implementation
details. In particular, it should avoid exposing the nature of any "hidden"
arguments to method functions, as these can vary based on the implementation
strategy and the features supported. This goal may preclude the definition of
a useful set of publicly-available primitive hooks.
* Relation to Defstruct
Unfortunately, any object system is likely to have a significant overlap with
Defstruct. We must consider reducing the redundancy, either by defining the
object system as a variant/extension of defstruct (ugh), or by flushing
defstruct (hard).
* Messages to Non-Instances
It is desirable that messages can be sent to any Lisp object, not just
instances. Problems might arise if we attempt to allow users to define
methods for non-instances, particularly if we intend to support multiple
coexisting objects systems. Certainly, we would have to clearly define the
type hierarchy for the primitive types.
* Retroactive Changes
Once message passing exists in Common Lisp, many things could be redefined to
take advantage of it. For example, the stream functions could be defined in
terms of message passing, allowing users to define new stream types. How much
redefinition should be done?
* Encapsulation
In my opinion, a major design issue is encapsulation, meaning the ability to
separate the implementation of a "class" from its external interface, allowing
implementation changes that do not change the external interface to be
relatively transparent to users. Although encapsulation is claimed to be one
of the important features of object-oriented programming, the objects
languages that I have seen all fail to support encapsulation in their
definitions of inheritance. I am working on a proposal that fully supports
encapsulation, but in its present form I know it will be unacceptable to those
who take advantage of some of the less disciplined features of other systems.
This area is one where I would prefer to start with a conservative definition
(that does not destroy encapsulation) rather than immediately endorsing the
more powerful but less disciplined features.
-------
∂31-Oct-84 1606 HANDERSON%cmu-cs-c.arpa@csnet-relay.arpa Goals and Major Design Principles (violent reply)
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 31 Oct 84 16:06:12 PST
Received: from cmu-cs-c.arpa by csnet-relay.arpa id a001449; 31 Oct 84 18:47 EST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Wed 31 Oct 84 18:45:43-EST
Date: Wed, 31 Oct 1984 18:45 EST
Message-ID: <HANDERSON.12059932109.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson%cmu-cs-c.arpa@csnet-relay.arpa>
To: AS%hplabs.csnet%csnet-relay.arpa@csnet-relay.arpa
Cc: cl-object-oriented-programming%su-ai.arpa%csnet-relay.arpa@csnet-relay.arpa
Subject: Goals and Major Design Principles (violent reply)
In-reply-to: Msg of 31 Oct 1984 15:50-EST from AS%hplabs.csnet at csnet-relay.arpa
You standardize a language in order to write (MANY) portable programs - you do
NOT standardize everything written in it. I sincerely doubt that any single
object system can reflect even the few views that have been presented so far.
I am a user, and I would like to be able to use LOOPs, Flavors, and anything
else that comes along in the comfortableness and cleanliness of my own Common
Lisp. I am not qualified to say "This is good, this is bad."
"Advantage comes from what is; usefulness comes from what is not." [The Tao]
As for small machines, let's not design for obsolescence, huh? Very fast,
cheap and REAL machines are beginning to become available. Let's plan for it,
instead of against it. Real things should be done on real machines.
Re: defstruct. Defstruct is single-inheritance; Flavors is multiple. Very
different. There are different tools for different uses. You don't open a
paint can with a sharp knife. It's always possible that someone will invent a
sharp-knife/paint-can-opener in one, but you don't waste your time trying to
figure one out. There are entire catalogs of bogus tools that nobody uses [I
guess if you buy one, you're apt to buy many].
Trying to redefine everything to use message passing is a good way to create a
blob of string that nobody can separate, as well as to slow otherwise fast
things down. We have an editor that is more powerful and faster than the Lisp
Machine's, mostly BECAUSE it was written without Flavors (it's also fairly
portable).
We DO need standardization to do things like have the lisp system be able to
talk to different object systems. Once we have this, then we can worry about
defining streams and such. I'm not sure how possible this is, or even if it's
especially desirable. [Yeah, it's fun, but...] It could be that all we need
to do is standardize on there being a message name and arguments, and then have
some system SEND operation that various object systems can interface to. [Like
have it dispatch on the name of the instance's object system to get the sending
function] This has possiblities.
-- Steve
∂31-Oct-84 2123 FAHLMAN@CMU-CS-C.ARPA Goals
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 31 Oct 84 21:22:58 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 1 Nov 84 00:23:00-EST
Date: Thu, 1 Nov 1984 00:22 EST
Message-ID: <FAHLMAN.12059993508.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: cl-object-oriented-programming@SU-AI.ARPA
Subject: Goals
I guess I'll toss in my thoughts about what we might want to accomplish.
First, there is a lot of demand among potential Common Lisp users for a
Flavor system that is either compatible with the current Lisp Machine
system, or is a slight improvement in ways that the various Lisp Machine
companies will fully support. Some of these users actually seem to
think that Flavors is the right thing. Some of them have no idea what
the issues are and are using the term "flavors" generically. Most,
however, have existing code developed on 3600's that they want to port
to other systems, or plan to move back and forth across this boundary in
the future. If we don't met this need, we end up splitting the Common
Lisp community into those who use flavors and those who don't, with no
code-sharing between them.
The way flavors are used by Lisp machine people, they have to be quite
efficient, and that means a small amount of low-level,
machine-dependent, non-portable support. Given this low-level support
in some standard form, it is possible to keep most of the flavor system
code fully portable. So if we define the portable flavor system in two
parts, each implementation that wants flavors will be able to implement
a very small implementation-dependent kernel, grab the file of portable
public-domain flavor code, and they've got it.
A separate question is whether this standardized flavor-support kernel
should go into the white pages. Should something be allowed to call
itself a Common Lisp if no flavor system is available, or should we
require this support machinery so that code using flavors is guaranteed
to be portable? Maybe the issue would go away if we could provide a
file of code that implements the low-level flavor support entirely in
portable Common Lisp. The resulting flavor system would be slow, and
perhaps not too useful because of that, but it would be legal.
Implementations that wanted a FAST flavor system would have a clear and
finite set of things to improve.
So much for Flavors. A different but related issue is what a really
good object-oriented system might look like. I was among those who
opposed including flavors or any other object-oriented system in the
first pass of the Common Lisp definition because I don't think anyone
has got it right yet. Without going into a lot of flames about what is
wrong with flavors, I think that a lot of people see the flavor system
as being much too complex. This results from wanting the system to have
completely flexible multiple inheritance, late binding, and still have
everything compiled as tensely as possible. I think that those are
basically incompatible goals, and if you push a little too hard on them
you get exponential growth in complexity for very little gain. Maybe
after we've all had as much experience with these things as the Lisp
Machine people, we'll all come around to their point of view; then
again, maybe they're wedged. In any event, the only way that a
consensus is going to emerge on this is for people to play with a
variety of object-oriented styles, flavors included. The idea of making
controversial mechansims spend some time in the yellow pages to see if
people like them seems especially appropriate here.
So what can we do? Some users feel that they need a portable flavor
system, with low-level support that does not give away ANY performance
for generality. I was hopeful that the same set of non-portable
mechanisms that we need for implementing a portable flavor system would
also be a good substrate for exploration of other object-oriented
systems. If we can come up with such a common kernel for objects, that
would be the best answer, whether or not we put it in the white pages.
But if this is impossible, maybe we will have to have one very
specialized, very tense kernel for flavors, and a more general kernel
for experimentation with other object-oriented paradigms.
Then again, maybe there's enough horsepower in this group for someone to
come up with an object oriented system that we will all love at first
sight.
-- Scott
∂31-Oct-84 2212 Moon@SCRC-QUABBIN.ARPA What are we talking about?
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 31 Oct 84 22:11:09 PST
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 97920; Wed 31-Oct-84 23:15:59-EST
Date: Wed, 31 Oct 84 23:18 EST
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Reply-To: cl-object-oriented-programming@SU-AI.ARPA
Subject: What are we talking about?
To: cl-object-oriented-programming@SU-AI.ARPA
Message-ID: <841031231806.9.MOON@EUPHRATES.SCRC.Symbolics>
Perhaps we should be talking about the charter of the object oriented
programming interest group, rather than about details.
I believe that Common Lisp is not a complete programming system in itself, and
was not intended to be. I believe Common Lisp is a substrate-building tool and
a method for enhancing portability. It is a language, not a programming system.
My belief is that Common Lisp should not specify a particular method of
object-oriented programming, any more than it should specify a particular
AI knowledge representation system or a particular display terminal.
I believe that the Common Lisp white pages should be augmented with the
necessary facilities to make it possible to write a variety of efficient,
portable, yellow-pages object-oriented programming systems. Multiple
object-oriented programming systems should be able to coexist simultaneously
in the same Lisp environment. People building applications should be able
to select whichever object-oriented programming system(s) they prefer
for the particular task; there should be a marketplace of ideas.
The charter of this group should be to specify those white-pages facilities
required for the building of object-oriented programming systems, to see that
they are implemneted in our respective implementations, and to encourage the
production of several object-oriented programming systems. The first systems to
be implemented should probably be Common Lisp versions of systems such as
Flavors and Loops that are already popular.
What are the criteria for inclusion of some feature in these white-pages
facilities, which might be called the object-oriented programming kernel?
The fundamental criterion is that a feature is included if it is necessary
or desirable for it to be implemented in an implementation-dependent way
rather than a portable way. The two reasons I can think of for this are
(1) efficiency, and (2) close interaction with implementation-dependent
mechanisms such as function-calling, variable-accessing, or the compiler.
What are the criteria for -not- including some feature in the object-oriented
programming kernel? Anything that can be implemented in portable Common Lisp
code, even if every implementation of every object-oriented programming system
ends up using the same code, should not be included. Anything that involves
controversial issues should not be included, because people will not agree
and because it would be wrong (for Common Lisp) to try to force them to agree.
I'm sure it will not be possible to attain a perfect separation between
kernel features and controversial issues, but that is what we should aim for.
To sum up: Mechanisms should be in the kernel. Policies should be outside.
Howard Cannon wrote an (incomplete) proposal for how to do this two or three
years ago. It was geared to the kernel features necessary to implement flavors,
but that appears to subsume what most other Lisp-based object-oriented
programming systems require. Steve Handerson has an implementation on the
PERQ of something resembling this proposal. These might be good places
to start. I've had enough experience with both of these to know that it won't
be easy; making these mechanisms both efficient and portable to our wide
range of architectures isn't easy.
By the way, if this is all too vague for you, and you want to hear something
concrete, I'll just mention that Flavors have active values already and have
always had them.
∂01-Nov-84 0704 FAHLMAN@CMU-CS-C.ARPA Goals
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 1 Nov 84 07:01:36 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 1 Nov 84 10:01:31-EST
Date: Thu, 1 Nov 1984 10:01 EST
Message-ID: <FAHLMAN.12060098826.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: cl-object-oriented-programming@SU-AI.ARPA
Subject: Goals
I basically agree with Moon's views on what level of stuff should go
into the white pages (or some semi-standard: you don't have to do this,
but if you do you should do it this way), and therefore what this group
needs ultimately to decide. My somewhat rambling message of last night
was meant only to indicate that even this is not an easy problem for
several reasons:
1. There is great demand for the best possible substrate for a flavor
system. Many of the Lisp Machine people understandably oppose a
mechanism that would slow down flavors even a little bit in the interest
of generality, or that would not support some of the more complex
features of flavors.
2. Any kernel needs some sort of method-lookup support that can handle
multiple strands of inheritance, some sort of mechanism for accessing
instance variables from methods, probably a separate instance data type
for cleanliness (instances could in principle be built as structures,
but we probably want them to print differently, etc.), and maybe some
sort of low-level mechanism for efficient implementation of active values.
3. Even in that small set of mechanisms there is some difficulty. For
example do instance variables look to a method writer like lexical
variables, special variables, or something else? To what lengths do we
want to go to support late binding: methods referencing instance
variables when the instance-defining flavors or classes have not yet
been defined or might change? And so on.
Anyway, my point is that even if we want to confine our final output to
a single set of low-level non-portable mechanisms, we may need to
discuss the higher-level issues in order to understand the range of
things that need to be supported, and to see if a consensus exists on
any of this stuff. If everyone agrees that instance variables in self
should look like lexical variables bound at the time of a send, then
we've got a useful constraint; if someone deeply believes that these
things should look some other way, then we have to think about whether
we can accommodate both views.
Probably the best way to make progress (after the initial goal-setting
period) is to begin circulating proposals for the low-level stuff and to
see where the sticking points really are. A specific proposal tends to
crystallize the argument in a way that a more general discussion will
not.
-- Scott
∂01-Nov-84 0927 GRISS%hp-hulk.csnet@csnet-relay.arpa Re: What are we talking about?
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 1 Nov 84 09:26:47 PST
Received: from hplabs by csnet-relay.csnet id a005632; 1 Nov 84 12:22 EST
Received: by HP-VENUS id AA13670; Thu, 1 Nov 84 04:40:31 pst
Message-Id: <8411011240.AA13670@HP-VENUS>
Date: Thu 1 Nov 84 04:41:06-PST
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Re: What are we talking about?
To: cl-object-oriented-programming%su-ai.arpa@csnet-relay.arpa
Cc: GRISS@hplabs.CSNET
In-Reply-To: Message from ""David A. Moon" <Moon@SCRC-STONY-BROOK@HP-VENUS>" of Thu 1 Nov 84 00:18:16-PST
Source-Info: From (or Sender) name not authenticated.
I appreciate the minimality sentiments expressed; I actually think
these are the same sentiments that should also direct the design of a subset
... ie, are there generally useful things ALREADY in Common LISP
that can be easily and effectively expressed in a portable way in
terms of a subset; if so, is it fair game to discuss their removel to
"blue" pages for an approved subset.
M
-------
∂01-Nov-84 1136 FAHLMAN@CMU-CS-C.ARPA What are we talking about?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 1 Nov 84 11:36:23 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 1 Nov 84 14:35:30-EST
Date: Thu, 1 Nov 1984 14:35 EST
Message-ID: <FAHLMAN.12060148702.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Martin <GRISS%hplabs.csnet@CSNET-RELAY.ARPA>
Cc: cl-object-oriented-programming@SU-AI.ARPA
Subject: What are we talking about?
In-reply-to: Msg of 1 Nov 1984 07:41-EST from Martin <GRISS%hplabs.csnet at csnet-relay.arpa>
Martin,
I think the situations are very different. In the object-oriented game,
we as a group (and some of us as individuals) don't really know what we
want yet. The idea of putting in a minimal and general set of hooks is
to let a thousand flowers bloom, so that we can all get some experience
with the different possibilities and then, maybe, someday, reach a
consensus on what we all like.
Subsets are different. In the language as currently defined in the
white pages, we deliberately put in a lot of high-level stuff that could
have been defined in terms of more primitive constructs precisely
because we did not want a thousand flowers to bloom. Things made it
into the white pages whenever we felt confident that a large number of
users would want them and that we understood these things well enough to
know that the facility as provided is about as good as any other way of
doing it. In these cases, leaving the decision unbound would just
promote incompatibility, not useful diversity.
Of course, anyone implementing a Common Lisp would be foolish to ignore
the fact that some of these things can be defined in terms of others.
In fact, we provide public-domain code for an awful lot of these things,
and any very tiny system could either auto-load just what it needs or
could purge whatever it doesn't need at system-delivery time. Very
little has to be implemented by hand as the lowest-level support.
-- Scott
∂01-Nov-84 1209 HANDERSON@CMU-CS-C.ARPA Begging the question
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 1 Nov 84 12:09:43 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Thu 1 Nov 84 15:09:36-EST
Date: Thu, 1 Nov 1984 15:09 EST
Message-ID: <HANDERSON.12060154903.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To: cl-object-oriented-programming@SU-AI.ARPA
Subject: Begging the question
In-reply-to: Msg of 1 Nov 1984 14:35-EST from Scott E. Fahlman <Fahlman>
Ok, Dave, what kind of active values are already present in Flavors?
-- Steve
∂01-Nov-84 1736 STICKLEN@RUTGERS.ARPA Goals?
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 1 Nov 84 17:36:12 PST
Date: 1 Nov 84 20:34:56 EST
From: Jon Sticklen <STICKLEN@RUTGERS.ARPA>
Subject: Goals?
To: cl-object-oriented-programming@SU-AI.ARPA
i feel a bit uneasy about some of the messages in this forum.
what ARE the purposes here? if the purposes are to define a
"kernel" as per moon's suggestion (which on the surface seems
reasonable to me) then the participation in this discussion can be
drastically limited to people like danny bobrow and mark stefik (on
the LOOPS side), danny weinreb and david moon (on the FLAVORS side)
and of course others. the point is that if a core is to be constructed
that will allow the various object oriented languages to be built on
top of it, then the right people to carry on the discussion are the
IMPLEMENTORS of the various extant systems. IF on the other hand the
goal is to set out what is desired in a uniform object oriented
language for CommonLisp, then there is still a place for USERS (like
me).
so it would seem to me that the FIRST order of business is decide what
this discussion is to be about.
one recent message seemed to be suggesting that because some folks
have a lot invested in FLAVORS based software, that therefore the
resultant standard should look a lot like FLAVORS.
if you take the time to look around a bit, you'll discover that others
have a lot invested in LOOPS based software.
but the real issue is that these concern over who has how much
invested in what should @b<@u(NOT)> be the driving concern for
setting this standard, at least i don't think so.
if, as someone suggested, noone knows the right way to do object
oriented systems yet, then moon's suggestion takes on even greater
weight.
---jon---
-------
∂01-Nov-84 2135 Kahn.pa@Xerox.ARPA Re: What are we talking about?
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 1 Nov 84 21:35:06 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 01 NOV 84 21:34:49 PST
Date: 1 Nov 84 11:36 PST
From: Kahn.pa@XEROX.ARPA
Subject: Re: What are we talking about?
In-reply-to: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>'s message of
Wed, 31 Oct 84 23:18 EST
To: cl-object-oriented-programming@SU-AI.ARPA
cc: Kahn.pa@XEROX.ARPA
I too like the idea of minimality, of a minimal kernel for building
different object oriented systems on top of. What is a little odd is
that Loops as far as I know requires nothing that Common Lisp doesn't
already provide. The reasons for this are that
(1) objects are not functional objects so Funcall, etc. doesn't work on
them
(2) instance variables are wrapped in a macro call so that neither the
compiler nor interpreter need distinguish instance variables from other
Lisp variables.
(3) self is just passed as an argument so it doesn't need to be set by
any micro-code.
Active values.
How does flavors have active values? Its true that if one sends message
':foo and ':set-foo then via method combination one can do all that
active values do. But its not normal practice to send those messages to
self.
Or do you mean that one can use ZetaLisp's monitor-variable to capture
activeness on updating. If so then what about access?
Defstruct vs Defflavor. I agree with Alan Synder that there is
significant overlap here. I find that too often I start with a
defstruct only to reach some limitation and re-write it as a defflavor.
At least the syntax of the two forms should be as similar as possible to
make it easier to convert. More ambitious merging of the two is
probably very hard.
∂02-Nov-84 1654 RWK@SCRC-STONY-BROOK.ARPA Goals and Major Design Principles (violent reply)
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 Nov 84 16:51:33 PST
Received: from SCRC-HUDSON by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 119875; Fri 2-Nov-84 10:25:05-EST
Date: Fri, 2 Nov 84 10:24 EST
From: "Robert W. Kerns" <RWK@SCRC-STONY-BROOK.ARPA>
Subject: Goals and Major Design Principles (violent reply)
To: Steven <Handerson@CMU-CS-C.ARPA>
cc: AS%hplabs.csnet@CSNET-RELAY.ARPA,
cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: <HANDERSON.12059932109.BABYL@CMU-CS-C.ARPA>
Message-ID: <841102102453.9.RWK@HUDSON.SCRC.Symbolics.COM>
Date: Wed, 31 Oct 1984 18:45 EST
From: Steven <Handerson%cmu-cs-c.arpa@csnet-relay.arpa>
Re: defstruct. Defstruct is single-inheritance; Flavors is multiple. Very
different. There are different tools for different uses. You don't open a
paint can with a sharp knife. It's always possible that someone will invent a
sharp-knife/paint-can-opener in one, but you don't waste your time trying to
figure one out. There are entire catalogs of bogus tools that nobody uses [I
guess if you buy one, you're apt to buy many].
On the other hand, you could go broke (run out of space, fill up your
bookshelf, confuse yourself) buying lots and lots of single-purpose
tools. A 2x4 cutter. An interior-grade-plywood cutter. A masonite
cutter. Or you could buy a table saw.
I have found that flavors have replaced about 90% of my usage of
DEFSTRUCT, and I find it difficult to justify much of the remaining
10%. Instead of writing lots of (MY-STRUCT-FOO STRUCT)'s, I use a
lot of FOO's, and I probably gain as much efficiency from using
instance variables as I give up in calling the methods. I think
a lot of people think in terms of replacing every (MY-STRUCT-FOO STRUCT)
with a message-pass. This is not the way you use a message-passing
system! Much of the code that you used to write "outside" the
DEFSTRUCT you'll write "inside" the object, and access the instance
variables directly.
Trying to redefine everything to use message passing is a good way to create a
blob of string that nobody can separate, as well as to slow otherwise fast
things down.
I didn't see him say that everything has to use message passing! It is
quite possible to have objects that you don't manipulate via message
passing, but are still "objects", and also SUPPORT message passing.
For example, I firmly believe the integer 6 should support the
:PRINT-SELF message. That doesn't mean I believe the + operator should
be implemented using message-passing, at least in the INTEGER+INTEGER
case! DEFSTRUCT accessors don't have to send messages, either, even if
named-structures are build using instances of some object-system.
We have an editor that is more powerful and faster than the Lisp
Machine's, mostly BECAUSE it was written without Flavors (it's also fairly
portable).
This is nonsense! The Lisp Machine editor was written without flavors
as well, since it was done before flavors! Even today, for most structures
it doesn't use flavors. Where it does use them, it doesn't use message
passing for the commonly-accessed instance variables, so it's probably
FASTER than using DEFSTRUCTs, on our system at least.
If you've got a faster editor (faster doing what?), it's either because
you're comparing it against the old LM-2/CADR architecture, or you're
running without a reasonable amount of memory, or because you've done a
truly outstanding job on your Lisp, your editor system.
We DO need standardization to do things like have the lisp system be able to
talk to different object systems. Once we have this, then we can worry about
defining streams and such. I'm not sure how possible this is, or even if it's
especially desirable.
I think it's possible, and desirable. I think it's important to
standardize on certain message-passing PROTOCOLS. This is quite
independent of what object-system you implement. The stream protocol is
one example; if I have an editor stream, written using flavors, I should
be able to bring it (and flavors) to a system using something else, and
be able to print to my stream. Similarly, I should be able to take a
pretty-printer that talks to LOOPS-based streams to a flavor-system and
use it there.
I don't think we're ready to try to do any of this yet. (Nor do we yet
have to agree that it's the right thing). I think this is way down on
the agenda.
∂02-Nov-84 1907 Moon@SCRC-STONY-BROOK.ARPA active values
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 Nov 84 19:06:55 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 120516; Fri 2-Nov-84 22:04:45-EST
Date: Fri, 2 Nov 84 22:04 EST
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: active values
To: Kahn.pa@XEROX.ARPA, Steven <Handerson@CMU-CS-C.ARPA>
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: The message of 1 Nov 84 14:36-EST from Kahn.pa@XEROX.ARPA,
<HANDERSON.12060154903.BABYL@CMU-CS-C.ARPA>
Message-ID: <841102220427.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 1 Nov 1984 15:09 EST
From: Steven <Handerson@CMU-CS-C.ARPA>
Ok, Dave, what kind of active values are already present in Flavors?
Date: 1 Nov 84 11:36 PST
From: Kahn.pa@XEROX.ARPA
How does flavors have active values? Its true that if one sends message
':foo and ':set-foo then via method combination one can do all that
active values do.
Exactly.
But its not normal practice to send those messages to self.
Not so. It depends on the particular programming style employed. Many
people use messages to access logical values that happen to be stored
directly as instance variables, especially people who use active values.
∂09-Nov-84 1337 Kahn.pa@Xerox.ARPA Re: Status Of CL Object Oriented Group?
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 9 Nov 84 13:37:02 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 09 NOV 84 13:27:40 PST
Date: 9 Nov 84 13:28 PST
From: Kahn.pa@XEROX.ARPA
Subject:Re: Status Of CL Object Oriented Group?
To: cl-object-oriented-programming@SU-AI.ARPA
The group has been quiet for about a week. Maybe people don't have much
more to say about instance variables. I'll try to summarize soon what I
think people did say about it.
A new issue we can discuss is the interface between Lisp and objects.
Some of the issues here need to be answered even if we take the approach
of specifying what hooks and primitives need to be in Common Lisp so
everyone can implement their favorite object system.
** How should Lisp send a message? **
Should this be standardized? If so should the selector be quoted? Do
people like the idea of a macro named "send"?
** What should happen if a message is sent to a Lisp datatype? **
Should this be an error? Should there be a way to define methods for
Lisp datatypes? If so, should they be associated with the name of the
data type or what?
(Loops is in the process of experimenting with this now and we are
finding it very useful. It also permits one to write functions that
work equally well on objects as lists, etc. )
If the overhead of the send to a Lisp datatype can be compiled away
then perhaps lots of system code should send messages even when by
default the objects are just lists or arrays. I/O streams and windows
are examples where this probably makes sense.
** What should happen if a Lisp primitive is called with an object as an
argument? Should car and cdr send messages to their args in such a
case? What about plus? print? This issue is important because one
sometimes writes objects to implement some exotic kind of number or list
and wants these objects to integrate well with existing code. What
should type-of of an object return? What should eval of an object do?
----- End Forwarded Messages -----
∂09-Nov-84 2006 HANDERSON@CMU-CS-C.ARPA Various thoughts and opinions
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 9 Nov 84 20:06:35 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Fri 9 Nov 84 23:00:40-EST
Date: Fri, 9 Nov 1984 22:54 EST
Message-ID: <HANDERSON.12062336722.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To: cl-object-oriented-programming@SU-AI.ARPA
Subject: Various thoughts and opinions
In-reply-to: Msg of 9 Nov 1984 16:28-EST from Kahn.pa at XEROX.ARPA
The only reason we would want to standardize *anything* is if Common Lisp has
to talk to an object system, as is the case with CAR of an object. We don't
even have a kernel for Flavors yet, so I don't think there's much point in
discussing a general kernel. Assuming the kernels are well-designed and easy
to implement, it won't kill to have two or three. There's not really much
point in standardizing send if you don't get any primitives out of it.
If the sending operation is a macro or defsubst or something, it can look at
the send to see if the operation is a constant (for inline expansion or
whatever). One of the major differences between send and a function call is
that the operation can be a computed quantity. Is that what you meant by
quoting the selector?
If we don't standardize sending, then we shouldn't standardize how to send to
non-instances. We could make up a list of suggested operation names and
arguments, though. Some are obvious, like 'LISP:CAR and 'LISP:PRINT, but more
complicated operations might be a problem. I haven't thought about this too
much.
I feel pretty strongly that if you know something is a list, you should use CL
functions instead of sending messages. Code analysis tools (like compilers)
will then know what you're talking about. On the other hand, changing the
behavior of lisp primitives is something entirely different and possibly very
fruitful. This would allow you to (fairly efficiently) use the same operation
(lisp functions and functions written with them) for instances and
non-instances. Still, you want to do the "normal" thing fast, and then have
exception handling for the unusual thing, not vice-versa.
If each instance has an object-system-name as part of its known structure, and
if we associate a sending function (with agreed-upon arguments) with each
object-system-name, then CL primitives could simply find the appropriate
sending function and invoke it. The arguments would probably be something like
(object operation-name . arguments), where the operation-names are
standardized. Flavors (and LOOPS, I think) should be able to just put their
sending functions in as the interface. Since there are going to be a finite
number of known operations, the sending function could itself do the
dispatching if necessary. These operations probably want their own package.
Typing such objects is a problem, one I'm not really qualified to talk about.
Presumably you want the system to use typep wherever possible, so that the
object can decide if it wants to be a cons or not. Typep for "simple" types
could and should be fast, but for objects it should send a message using the
above interface.
-- Steve
∂16-Nov-84 1255 DLW@SCRC-STONY-BROOK.ARPA Instance variables
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Nov 84 12:54:54 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 128489; Fri 16-Nov-84 13:03:54-EST
Date: Fri, 16 Nov 84 13:03 EST
From: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Subject: Instance variables
To: Handerson@CMU-CS-C.ARPA, Kahn.pa@XEROX.ARPA, Fahlman@CMU-CS-C.ARPA,
cl-object-oriented-programming@SU-AI.ARPA, STICKLEN@RUTGERS.ARPA
Message-ID: <841116130318.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
Sorry for the late replies; I just got around to reading all of my
Common Lisp mail. This is mostly about the meta-issue of what we should
be discussing.
I also strongly agree that we should be trying to discover a set of
primitive hooks that every implementation can provide, so that several
message-passing systems can be provided in a yellow pages library. For
us to try to design a single message passing system and try to impose it
on all the users would be a mistake. Therefore, there's no need for us
to send mail saying which way message passing should work; rather we
should try to assemble a list of requirements that will drive the
definition of the primitive hooks.
Those of us who are familiar with existing systems such as flavors or
loops can contribute by making sure that the primitive hooks will be
sufficient to produce a reasonably efficient implementation of that
system. We'll have to work together on this, since probably nobody is
familiar with the requirements of all systems.
If we can agree on this strategy, then we can keep this discussion more
focussed and useful. For example, the issue of "but isn't defstruct
sort of similar" should be postponed, since it is very unlikely to
affect the design of the primitive hooks.
As Scott Fahlman says, we will have to discuss some of the higher-level
issues (how should variables work, how should inheritance work), but we
need not get agreement on all of them. If we all agree about some
issue, then we can feel free to make the primitive hooks support the
agreed answer; if it seems clear that we do not agree about some issue,
then rather than argue it to death, we can just try to design the
primitive hooks to support various different answers.
I'd like to reply to one thing that Scott said:
Date: Thursday, 1 November 1984, 10:01-EST
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
1. There is great demand for the best possible substrate for a flavor
system. Many of the Lisp Machine people understandably oppose a
mechanism that would slow down flavors even a little bit in the interest
of generality, or that would not support some of the more complex
features of flavors.
Well, actually, if there's some big conflict here, it need not cause a
breakdown in cooperation. Just because there is a set of primitives
that each implementation must implement, and there is a yellow-pages
implementation of flavors, does not mean that we are required to use
that implementation; we could provide the hooks, but keep using our
existing implementation that doesn't use those hooks. Of course, it
would be better to avoid such a situation, but if worse comes to worst,
we could do it.
I'd also like to reply regarding one specific technical point, namely,
the "lexical" behavior of instance variables:
Date: Wednesday, 31 October 1984, 15:58-EST
From: Steven <Handerson@CMU-CS-C.ARPA>
but it is my strong opinion and belief that
instance variables are naturally lexical (accessible only inside methods).
In the implementation of Flavors that will be included in our next
software release (Rel 6.0), this is exactly how it works. A lambda
expression that is closed inside a method can refer to the instance
variables of the instance, as a natural extension of the meaning of
lexical scoping.
Date: Wednesday, 31 October 1984, 17:17-EST
From: Kahn.pa@XEROX.ARPA
I like the notion of thinking of a DEFMETHOD as something that expands
to a giant LET binding the instance variables to their values. The
problem then is with SETQ and the like.
Flavors sort of takes the view that an object is a functional closure
and that DEFMETHOD "edits" the definition of the function.
I don't understand this; what's the problem with SETQ? An internal
function of a method can SETQ the instance variables just fine, even if
it's returned (i.e. even if it is an "upward funarg").
∂19-Nov-84 1012 "Kahn.pa"@Xerox.ARPA Re: Instance variables
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 19 Nov 84 10:12:18 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 19 NOV 84 10:09:42 PST
Date: 19 Nov 84 09:39 PST
From: Kahn.pa@XEROX.ARPA
Subject: Re: Instance variables
In-reply-to: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>'s message of
Fri, 16 Nov 84 13:03 EST
To: cl-object-oriented-programming@SU-AI.ARPA
cc: Kahn.pa@XEROX.ARPA
I'm seeing a consensus that we should concentrate first on defining
hooks into Common Lisp for implementing Flavors, Loops, and the like.
If there are people out there that think that this is a mistake but have
been too busy or shy to contribute to this discussion, now's the time to
put forth an alternative.
Regarding my comment about SETQ of instance variables.
Of course there is no problem if you view methods (or objects) as
closures. What I was referring to is the idea that a method is an
ordinary function with an implicit (LET ((var-1 (GetValue var-1 ..)) ...
(var-n (GetValue var-n ..))) ...) around it.
I have question for Flavors people. "self" is treated specially by the
micro-code rather than being a special variable. Do you think it
reasonable for Common Lisp to hack "self" or would you be happy with
just send and give up on funcall for message passing? Loops passes
"self" around as the first argument and its just an ordinary lambda
variable which can have any name. Does flavors require "self" to be
treated specially and if so what do you propose Common Lisp do about it?
>>Message<<
∂19-Nov-84 1418 Moon@SCRC-STONY-BROOK.ARPA Re: Instance variables
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 19 Nov 84 14:17:56 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 129953; Mon 19-Nov-84 17:19:53-EST
Date: Mon, 19 Nov 84 17:18 EST
From: "David A. Moon" <Moon@SCRC-QUABBIN.ARPA>
Subject: Re: Instance variables
To: Kahn.pa@XEROX.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: The message of 19 Nov 84 12:39-EST from Kahn.pa@XEROX.ARPA
Message-ID: <841119171810.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 19 Nov 84 09:39 PST
From: Kahn.pa@XEROX.ARPA
I have question for Flavors people. "self" is treated specially by the
micro-code rather than being a special variable. Do you think it
reasonable for Common Lisp to hack "self" or would you be happy with
just send and give up on funcall for message passing? Loops passes
"self" around as the first argument and its just an ordinary lambda
variable which can have any name. Does flavors require "self" to be
treated specially and if so what do you propose Common Lisp do about it?
I sure can't understand a word of this question. Which, if any, of the
following possible interpretation of your question is what you meant?
- Would Flavors people please discourse upon the difference between the
3600 and CADR implementations of flavors, with respect to the point that
in the CADR the variable SELF is special but in the 3600 it is lexical.
- Do we want instances of flavors to be usable as functions, with FUNCALL
and APPLY, or do we want them only to be invocable with SEND?
- What should the Common Lisp ARGLIST function return when given a method
as its argument?
- What parts of the mechanism for accessing instance variables supplied
by the proposed Common Lisp object-oriented-programming kernel should
be hidden, and what parts should be exposed to the portable programmer?
- Would Flavors people please discourse upon the virtues and/or uglinesses
of their DEFUN-METHOD feature.
∂19-Nov-84 1557 RPG
To: moon%scrc@MIT-MC.ARPA
CC: kahn@XEROX.ARPA,
cl-object-oriented-programming@SU-AI.ARPA
Instance Variables Re-transmission
Sorry, I was hacking on the mailing list when this message was
sent, and so it probably went to no one. This is a re-transmission:
∂19-Nov-84 1517 Kahn.pa@Xerox.ARPA Re: Instance variables
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 19 Nov 84 15:16:34 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 19 NOV 84 14:32:54 PST
Date: 19 Nov 84 14:35 PST
From: Kahn.pa@XEROX.ARPA
Subject: Re: Instance variables
In-reply-to: "David A. Moon" <Moon@SCRC-QUABBIN.ARPA>'s message of Mon,
19 Nov 84 17:18 EST
To: Moon@SCRC-QUABBIN.ARPA
cc: Kahn.pa@XEROX.ARPA, cl-object-oriented-programming@SU-AI.ARPA
Sorry I wasn't too clear.
[- Would Flavors people please discourse upon the difference between
the
3600 and CADR implementations of flavors, with respect to the point
that
in the CADR the variable SELF is special but in the 3600 it is
lexical.]
--- I didn't know that self was lexical on the 3600. The question is
how could one implement "self" without hooks into Common Lisp. Is
"self" a hidden instance variable? Can one bind it or set it explictly?
(This may be useful for explicit delagation or forwarding of messsages.)
[ - Do we want instances of flavors to be usable as functions, with
FUNCALL
and APPLY, or do we want them only to be invocable with SEND?]
--- This is related to the qustion of implementation. Isn't it the case
that on a 3600 FUNCALL and APPLY bind "self" or is this no longer the
case? If it is then perhaps Common Lisp needs a hook to accomplish
this.
[- What parts of the mechanism for accessing instance variables
supplied
by the proposed Common Lisp object-oriented-programming kernel
should
be hidden, and what parts should be exposed to the portable
programmer?]
---This is an interesting question though I wasn't asking it.
[- Would Flavors people please discourse upon the virtues and/or
uglinesses
of their DEFUN-METHOD feature.]
---This more related to what I was asking a couple of weeks ago.
Should instance variables look like Common Lisp variables and what's
involved in making that work?
∂19-Nov-84 1617 HANDERSON@CMU-CS-C.ARPA Instance variables
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Nov 84 16:14:28 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Mon 19 Nov 84 19:13:10-EST
Date: Mon, 19 Nov 1984 19:13 EST
Message-ID: <HANDERSON.12064917836.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To: Kahn.pa@XEROX.ARPA
Cc: cl-object-oriented-programming@SU-AI.ARPA
Subject: Instance variables
In-reply-to: Msg of 19 Nov 1984 12:39-EST from Kahn.pa at XEROX.ARPA
From: Kahn.pa at XEROX.ARPA
To: cl-object-oriented-programming at SU-AI.ARPA
Re: Instance variables
I'm seeing a consensus that we should concentrate first on defining
hooks into Common Lisp for implementing Flavors, Loops, and the like.
I'm worried about the words "for implementing." There will probably have to be
more than one substrate used by different object systems, and quite possibly
every major object system will have its own. Face it, LOOPS and Flavors aren't
that similar. There is a way we could have portable Flavors (using "symbol
macros"), but I guess Moon thought it was gross. We won't make it part of the
specs, but interested implementors can still use it to implement the eventual
kernel. [It doesn't have to be standard to be used.]
Methods are *implemented with* functions. Specifying the extra arguments is
like specifying an implementation - you could ruin a perfectly wonderful
implementation that way. Moon has pointed out that Symbolics has had three
implementations of Flavors, and each of them did message passing a different
way. LOOPS operations ARE functions, but only because there's nothing special
about them; instance variables aren't lexical and you can't compile instance
variables into fast code. This wins for things that change a lot, but not for
something fairly static like Flavors (which better be fast, or they won't get
used).
What I was suggesting is that we see what kind of hooks are necessary to allow
objects of all forms to do various useful things in the system. Some of these
would be analogous to things already accepted, like (print instance stream)
doing a (lisp::send instance 'print stream). Others might allow objects to
masquerade as other types, such as (CAR instance) doing a (lisp::send instance
'CAR). As I've said before, if we standardize (1) the functionality of this
lisp::send (meaning what messages and message arguments it gets used with), (2)
the way we tell objects from different systems apart, and (3) the way that
object systems provide translations of these messages into their own sends,
then that takes care of system hooks.
∂19-Nov-84 1826 Moon@SCRC-STONY-BROOK.ARPA Re: Instance variables
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 19 Nov 84 18:25:53 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 130100; Mon 19-Nov-84 21:27:50-EST
Date: Mon, 19 Nov 84 21:26 EST
From: "David A. Moon" <Moon@SCRC-QUABBIN.ARPA>
Subject: Re: Instance variables
To: Kahn.pa@XEROX.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: The message of 19 Nov 84 17:35-EST from Kahn.pa at XEROX
Message-ID: <841119212603.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 19 Nov 84 14:35 PST
From: Kahn.pa@XEROX.ARPA
Sorry I wasn't too clear.
Okay, let's try again.
[- Would Flavors people please discourse upon the difference between
the
3600 and CADR implementations of flavors, with respect to the point
that
in the CADR the variable SELF is special but in the 3600 it is
lexical.]
--- I didn't know that self was lexical on the 3600. The question is
how could one implement "self" without hooks into Common Lisp. Is
"self" a hidden instance variable? Can one bind it or set it explictly?
(This may be useful for explicit delagation or forwarding of messsages.)
SELF is just an ordinary variable on the 3600.
[ - Do we want instances of flavors to be usable as functions, with
FUNCALL
and APPLY, or do we want them only to be invocable with SEND?]
--- This is related to the qustion of implementation. Isn't it the case
that on a 3600 FUNCALL and APPLY bind "self" or is this no longer the
case? If it is then perhaps Common Lisp needs a hook to accomplish
this.
SELF is just an ordinary variable on the 3600.
[- What parts of the mechanism for accessing instance variables
supplied
by the proposed Common Lisp object-oriented-programming kernel
should
be hidden, and what parts should be exposed to the portable
programmer?]
---This is an interesting question though I wasn't asking it.
I think you should be, especially since your other questions seem to
presuppose a particular implementation of Flavors. There are many ways
to implement Flavors, and which one is appropriate for a particular
machine depends on characteristics of that machine and on what the
implementors want to do. That's why I believe the proposed Common Lisp
object-oriented-programming kernel should be at a higher level of
abstraction and should not commit itself to a particular mechanism, such
as binding a special variable named SELF or anything else. It should be
possible to implement that kernel in different ways on different
systems.
I'm afraid this discussion is pretty vacuous since it's not focussed on
a specific proposal. I wish I had time to write a treatise on the different
ways to implement Flavors, with four or five case studies, but I don't.
[- Would Flavors people please discourse upon the virtues and/or
uglinesses
of their DEFUN-METHOD feature.]
---This more related to what I was asking a couple of weeks ago.
Should instance variables look like Common Lisp variables and what's
involved in making that work?
It isn't Flavors if they don't. Handerson's proposal discusses what
is involved in making that work.
∂03-Dec-84 1649 HANDERSON@CMU-CS-C.ARPA Internals Proposal
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Dec 84 16:48:40 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Mon 3 Dec 84 19:47:17-EST
Date: Mon, 3 Dec 1984 19:47 EST
Message-ID: <HANDERSON.12068594031.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To: cl-object-oriented-programming@SU-AI.ARPA
Subject: Internals Proposal
In-reply-to: Msg of 19 Nov 1984 19:13-EST from Steven <Handerson>
Here is my proposal for the interface to the non-portable common part of object
systems. This basically solves the problem of how the object can specify how
it is to be printed, etc. This works well with standard object systems, and
can be made to work with nonstandard object systems, although not as easily.
It's mostly words, because so much of the internal stuff is
implementation-dependent; what I'm advocating is more of an approach.
DEFINITIONS
@i(Object system): any programming system with objects that are manipulated via
message passing. I claim the standard for Common Lisp is that a message
consists of an atomic message name or key, and some message arguments (not
unlike function arguments). An object system primitive is used to send
messages to an object.
@i(instance): an object belonging to a message system. This term has been
appropriated to refer to objects of the instance datatype, which implements
instances of all object systems that want access to the facility this paper
describes.
@i(Sending function): a function of the instance, message name, and arguments
(in that order) that sends a message to an instance belonging to a particular
object system. Althouigh it is fully intended that standard object systems can
use their primitive send as their sending function, this is not necessarily so.
The sending function could perform some translation of the message, and it need
not send a message to the object at all. [This is the case if you want to hack
up an object that acts like a list and a vector, for instance.]
LISP:SEND default-handler instance message-key . message-args [FUNCTION]
I decided to snarf the name in spite of its popularity; object systems that
want to call their sending primitive SEND will have to shadow it. Basically
this determines the sending function of the object system of the instance, and
calls it with the instance, message name and arguments. This is primarily
intended for the lisp system to communicate with instances from arbitrary
object systems, but other applications may have need for such a facility
(especially those that would be considered language extensions, such as error
systems). If the message is unhandled (see the section after the next), a
non-nil default handler is called with all arguments; otherwise, an error is
signalled.
THE INSTANCE DATATYPE
All objects are implemented with the same data type, which I call @i(instance).
The internal structure of this is up to the implementation; it may vary with
the particular object systems supported by the implementation, and with how
much effort the implementors want to put into it. Besides determining the
operations available on the object, the structure must of course eventually
point to the object system's sending function. Since everything here is
implementation-dependent, the best that can be done is to point out which
function in an object system is the sending function, so that it can be dealt
with appropriately by the implementation.
STANDARD MESSAGES AND LISP:UNHANDLED
The lisp system communicates with objects through a standard set of messages.
This set may be pretty large, though, and probably only a few will be relevant
to a given application. Also, if LISP::SEND comes to be used for other
applications, they will need to be able to determine whether the given object
handles the appropriate messages.
Some object systems have some seperate operation that examines the object to
see if it will handle a given message; this is not possible where most of the
"object" is a piece of code that dispatches off the message key. Also, some
applications (or at least Lisp) have some default behavior for a give object;
it's silly to expect all objects to know what this is, especially if that
information is duplicated over multiple object systems. I propose that the
sending function (and hence handlers) be allowed to return LISP:UNHANDLED,
which tells LISP:SEND that the message went unhandled and allows the default
action to take place. This certainly simplifies the task of writing sending
functions that allow objects to perform in arbitrary ways to lisp primitives,
and should also simplify the task of interfacing to a nonstandard object
system.
MUCKING WITH LISP TYPES
I think it would be neat to allow objects to masquerade as primitive types.
Basically instead of signalling a wrong-type-argument error, you do a send if
it's an object, with the default action being to go ahead and signal the error.
I think some experimentation or additional thought is called for, since this
could do horrible things to the notion of the type of an object, and probably
isn't appropriate to standard architectures. If this does happen, LISP::SEND
would be the way to do it.
EXAMPLES
Although the system was designed with making flavors:send be Flavors's sending
function, this probably won't be the case. Best would probably be to have
flavors signal a condition when a message was unhandled - the sending function
would be something that bound that condition and then did a send (the send
would probably be inline).
Some standard messages will be:
PRIN1 stream
TYPEP type
DESCRIBE
DUMPING-FORM
Returns a form that should create a like-behaving instance. Used by the
compiler to dump an instance.
∂03-Dec-84 2229 HANDERSON@CMU-CS-C.ARPA Internals Proposal
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Dec 84 22:29:36 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Tue 4 Dec 84 01:28:18-EST
Date: Tue, 4 Dec 1984 01:28 EST
Message-ID: <HANDERSON.12068656149.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To: cl-object-oriented-programming@SU-AI.ARPA
Subject: Internals Proposal
In-reply-to: Msg of 3 Dec 1984 19:47-EST from Steven <Handerson>
I'd like to make clear that the proposal I made in the previous post only
solves the problem of how applications (and lisp itself) communicate with
arbitrary instances, assuming they subscribe to this view. All that is needed
is to define the messages that must be understood by the instances. For
standard object systems, the translation (done by the sending function) from
these standard messages to object system messages will be minimal; other
applications may want to use an eq hashtable somehow (which should be fast).
Applications that only deal with one kind of object should of course use the
sending primitive, rather than lisp:send. If speed is not important and there
is a chance the code might want to be applied to objects of other systems, you
might consider using lisp:send.
Other proposals will have to deal with the separate issues of instance
variables, fast handler lookup, etc. As for whether such things are suitable
for white-pageness, I'm not sure. The Flavors kernel (being written) deals
with instance variables, but has to tie these up with all sorts of other things
(instance environments, method inheritance and hence method dependencies, etc).
It's sort of strange in that some basic language functions are being altered by
non-white-pages forms (e.g. (setq instance-variable 3) works inside a
defmethod), but everything's hunky dory if you think of the defining forms
(e.g. defmethod) as macros that torture the code.
∂05-Dec-84 1330 Bobrow.pa@Xerox.ARPA Re: Internals Proposal
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 5 Dec 84 13:29:35 PST
Received: from Riesling.ms by ArpaGateway.ms ; 05 DEC 84 13:30:11 PST
Date: 5 Dec 84 13:29 PST
From: Bobrow.pa@XEROX.ARPA
Subject: Re: Internals Proposal
In-reply-to: Steven <Handerson@CMU-CS-C.ARPA>'s message of Mon, 3 Dec 84
19:47 EST
To: Handerson@CMU-CS-C.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA, Masinter.pa@XEROX.ARPA,
VanMelle.pa@XEROX.ARPA,Bobrow.pa@XEROX.ARPA
Here is an alternative internal design for an object kernel, not
incompatible with that proposed by Steven Handerson.
The important difference between this design and that proposed by
Handerson is that it allows any datatype to act as a message receiver.
The LISP::SEND [[or ← as we spell it in Loops]] uses a unique identifier
of the datatype, DTID. [[In Interlisp-D/Loops this is an 8 bit
number.]] From DTID, one finds a class indicator [[Loops indexes into
an array]] and a MethodApplyFn, used to find and apply the function
which implements the method [[Loops encodes this in the class indicator
table]]. The functions LISP::CLASS and LISP::METHODAPPLYFN are user
handles on these two properties of a datatype.
The class indicator is one of
a) a class -- for datatypes which have the same class for all
instances
b) T, a well known value which means that the class is found in
in the first field of the datatype (a pointer field).
c) Another atom, FN, which is a function to be applied to the object to
find its class.
d) NIL meaning not a receiver -- ERROR
[[Loops uses (e) a dotted pair, (methodApplyFn . classIndicator), if
the standard built into ← is not to be used.]]
LISP::SEND then calls the MethodApplyFn function with the class,
selector, instance and the rest of the arguments. It finds the method
from the class associated with the selector, and if it exists, applies
the function to the arguments (in our case including the instance as
the first argument). If no such method exists then the message
MessageNotUnderstood <object><selector> <argList>
is sent to the object. All classes are guaranteed to have
some response to this message.
[[In Loops we ensure that all objects have a class, with the default
class (we call it Tofu, since it has no flavor) handling the two
messages
Understands <selector>
which standardly returns T if the class can
handle (understand) a message with that <selector>
MessageNotUnderstood which fields any message not understood.
This causes an ERROR or BREAK if no further behavior
is specified in a class.
Print <stream> ... which provides a default way of printing anything]]
For instance variable lookup, the class of any method is sent a message
CompileGetValue; the class should know how to compile instance variable
lookup code.
For interpretation of GetValue, the class of an object is sent a
message:
GetValue <object><ivName> ...
The class is an object itself, and it is responsible for knowing the
internal structure of instances of its type well enough to implement the
GetValue message.
∂07-Dec-84 1523 hpatlS!post%hplabs.csnet@csnet-relay.arpa hooks vs. subset (last try)
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 7 Dec 84 15:23:37 PST
Received: from hplabs by csnet-relay.csnet id ai14885; 7 Dec 84 18:08 EST
Received: by HP-VENUS id AA13611; Fri, 7 Dec 84 13:20:46 pst
Message-Id: <8412072120.AA13611@HP-VENUS>
Date: 7-Dec-84 13:19:18
To: cl-object-oriented-programming@su-ai.ARPA
Subject: hooks vs. subset (last try)
From: Snyder%hplabs.csnet@csnet-relay.arpa
Source-Info: From (or Sender) name not authenticated.
[If you have already seen this message, I apologize. Since I never received
it back from the mailing list, I am assuming it got lost somewhere along
the way and am sending it again.]
I would like to argue against the proposal that we concentrate on "defining
hooks into Common Lisp for implementing Flavors, Loops, and the like".
Although this is a worthy activity, I believe it would be more appropriate for
this group to attempt to define an extension to Common Lisp that can be used
by Common Lisp programmers who wish to program in an object-oriented style.
The charter of this group is to propose extensions to Common Lisp to support
object oriented programming. This group was created at the Monterey meeting
because the attendees felt that the area of object-oriented programming was
the most important area in which extensions to Common Lisp are required. (The
other popular areas were error handling, foreign function call, window
systems, and graphics.) The attendees did not state specifically why they
thought that extending Common Lisp to support object-oriented programming was
so important. In deciding which approach to follow, we should consider what
their (and our) desires are. We should also attempt to consider the desires
of the larger Common Lisp community, i.e., the potential users of Common Lisp,
not just the designers and implementers.
Here are a number of possible paraphrases for the statement "I believe that
Common Lisp should be extended to support object-oriented programming". Which
do you agree with? How strongly? Which do you believe the implementors of
Common Lisp agree with? Which do you believe the Common Lisp user community
would agree with?
1. I have one or more programs written using Zetalisp flavors and I want them
to run on any Common Lisp implementation. (Questions: Do the programs use
other features of Zetalisp that are not in Common Lisp? Can such features
be implemented using portable Common Lisp code? How will users of your
programs ensure that those features are supported in their systems? Do you
care how efficient the implementation of Zetalisp flavors is on any
particular Common Lisp?)
2. There exist one or more programs written using Zetalisp flavors that
I want to run on my Common Lisp. (Questions: same as previous.)
3. I like using Zetalisp flavors and want to be able to use it when I write
Common Lisp code. (Questions: Do you care how efficient the implementation
of Zetalisp flavors is on the Common Lisp you are using? Do you care
whether the Common Lisp programming environment you are using knows
anything about Zetalisp flavors?)
4. I don't know much about Zetalisp flavors, but I would like to experiment
using it on my Common Lisp system.
5. I have one or more programs written using LOOPS and I want them to run on
any Common Lisp implementation. (Questions: Do the programs use other
features of Interlisp that are not in Common Lisp? Can such features be
implemented using portable Common Lisp code? How will users of your
programs ensure that those features are supported in their systems? Do you
care how efficient the implementation of LOOPS is on any particular Common
Lisp?)
6. There exist one or more programs written using LOOPS that I want to run on
my Common Lisp. (Questions: same as previous.)
7. I like using LOOPS and want to be able to use it when I write Common Lisp
code. (Questions: Do you care how efficient the implementation of LOOPS is
on the Common Lisp you are using? Do you care whether the Common Lisp
programming environment you are using knows anything about LOOPS?)
8. I don't know much about LOOPS, but I would like to experiment using it on
my Common Lisp system.
9. (Similar questions for any other object-oriented Lisp extension.)
10. I want to use an object-oriented style of programming, but recognize
that there is no consensus on the details of object-oriented programming
constructs. Therefore, I want to be able to use various (existing or not
yet invented) objects systems in Common Lisp to help determine what the
"right" one is. Since each programmer individually chooses which objects
system to use, it is necessary that all objects systems run concurrently
in the same system to allow sharing of code written by others.
11. I have my own favorite objects system, but other people have different
ideas. The best way to get my favorite objects system to run in Common
Lisp is to ensure that the necessary hooks are a standard feature of every
Common Lisp implementation.
I am sure that for each of the above statements, there is some fraction of the
Common Lisp community that strongly agrees with the statement. I agree with
some of them, too, but I don't consider them top priority.
Below is my paraphrase of the above statement. I believe this statement is one
that many (potential) users of Common Lisp would agree with, but unfortunately
they are not "here" to express an opinion. I also speculate that many of the
attendees at the Monterey meeting that supported the creation of this
committee did so for this reason. (How many of said people are listening to
this discussion? I would like to know if you agree or disagree. Perhaps we
should raise this issue in the larger Common-Lisp mailing list, or by USmail
to the Monterey attendees.)
--------------------------------------------------------------------------------
12. I believe that object-oriented programming is "standard practice" for a
large part of the programming performed by myself and my colleagues. It
is as fundamental in my programming as functions are in traditional Lisp
programming. I wouldn't want to write code any other way. I believe that
the object-oriented style of programming is valid and useful for both low
level systems coding (such as implementing I/O or a window system) and
high level applications. For these reasons, I believe that no general
purpose programming language (including Common Lisp) is acceptable unless
it allows me to program in the object-oriented style.
As a user of Common Lisp, I therefore expect to find object-oriented
programming constructs available to me. I expect these constructs to be
sufficiently efficient that I am not dissuaded from using them because of
poor performance. I expect these constructs to be understood and
supported by the programming environment (the Common Lisp editor and
debugger) provided as part of my Common Lisp development system. I expect
these constructs to be documented in the documentation that comes with my
Common Lisp system. I expect any book on Common Lisp to teach me how to
use them. I expect the manufacturer of my Common Lisp system to
understand these constructs; if I have a problem, I expect the
manufacturer's representative to be able to help me. I want any
proficient Common Lisp programmer to be able to understand and maintain
code written using these constructs.
Although I have used various object-oriented languages, I understand that
Common Lisp may not use my favorite syntax or provide my favorite feature,
just as it differs from other Lisps in its syntax and feature set. I
accept these limitations in a desire to have a "common" Lisp used and
understood by many people.
--------------------------------------------------------------------------------
Thus, I do not consider object-oriented programming to be in the same category
as AI knowledge representation systems (Moon's example) or logic programming,
or any of a number of ideas that cannot yet be considered "standard practice"
for a wide range of programming tasks. Here the Monterey attendees apparently
agree with me, as they did not endorse an immediate need for Common Lisp
extensions to support AI knowledge representation systems, logic programming,
or even multiprogramming. (I was impressed with the ability of that large
group to focus on a small number of areas where extensions are urgently
required.)
I strongly doubt that defining only a set of hooks as a standard part of
Common Lisp will achieve the objectives of efficiency and support listed
above. Given the finite resources available to any manufacturer (or author,
for that matter), we cannot expect a manufacturer to support a nonstandard
objects system unless it becomes a de facto standard because of widespread
demand in the market. We certainly cannot expect manufacturers to support
multiple competing objects systems. If Common Lisp is to have a supported
objects system, agreement must be reached on a single standard. If we cannot
agree, who can?
Furthermore, it has yet to be shown that a set of portable low-level hooks
exists that can efficiently implement any one of the existing objects systems
on all Common Lisp implementations, much less all of them. I also doubt very
much that multiple coexisting objects systems can be efficiently supported.
Others have expressed similar doubts: Moon: "I've had enough experience with
both of these to know that it won't be easy ..." Fahlman: "... even this is
not an easy problem for several reasons". Handerson: "There will probably
have to be more than one substrate used by different objects systems, and
quite possibly every major object system will have its own."
Obviously there is a conflict between my claim that the object oriented style
of programming is "standard practice" and the widespread belief that years of
further experimentation will be required before the "right" object system is
designed. My belief is that there is a common kernel that we can all agree to
(probably roughly equivalent to Smalltalk) and that defining such a kernel as
a standard component of Common Lisp is most beneficial to the Common Lisp
community at large. If we think we can agree to a set of hooks, could we not
also agree on a set of constructs that are based on those hooks?
-- Alan Snyder
-------
∂08-Dec-84 1555 HANDERSON@CMU-CS-C.ARPA Bobrow's message, Snyder's message, Flavors kernel
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Dec 84 15:55:16 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Sat 8 Dec 84 18:55:55-EST
Date: Sat, 8 Dec 1984 18:55 EST
Message-ID: <HANDERSON.12069895439.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To: cl-object-oriented-programming@SU-AI.ARPA
Subject: Bobrow's message, Snyder's message, Flavors kernel
In-reply-to: Msg of 7 Dec 1984 13:19-EST from Snyder%hplabs.csnet at csnet-relay.arpa
My immediate reaction to Bobrow's message is that I'd like to keep Lisp:send
simple, and in particular not have it look like an object system (his looks
like LOOPS). Remember that LOOPS's sending function can resend
MessageNotUnderstood to the object if it wants (etc.).
I'd prefer, for sending to lisp types, a way to select a function based on the
lisp type, which would be separate from lisp:send. You'd do (if (instancep x)
(lisp:send x 'foo) (lisp-send x handler-object 'foo)), maybe as a macro. I
suppose lisp:send could do this automatically if it took a handler-object, but
you might want to send to an instance and treat it like a lisp type (isn't this
great? Yum). Basically the handler-object acts as the "type-type" or object
system of the lisp object, so that a cons interpreted as a Flavor can act
differently from a cons interpreted as a LOOPS object. I think this is
important, but maybe somebody else could explain why. Somebody who knows
something about the type system can design this.
My immediate reaction to Snyder's message is that object systems (especially
the part doing inheritance) are programs written in Common Lisp, and so if you
want to supply a real object-oriented programming *environment*, you're
basically reinventing the wheel. Yeah, maybe it's time to reexamine the
existing systems, but if we provide the necessary hooks to implement object
systems, we don't need to rush into anything. People can use Flavors in the
present form if they can stand it.
Standardizing on some unproven system might be a mistake. I think Flavors has
survived in its present form for the same reason that Fortran (which CL hopes
to replace) has survived (cost of rewriting, people getting used to it), and we
could easily make some similar mistake with another bogus system, although I
doubt we'd come up with anything as hairy. I feel sort of bad for propogating
a system like Flavors, but I think some of the basic concepts (NOT inheritance)
might be worth something.
Hence, my kernel tries to capture the ESSENCE of Flavors without the specifics
of inheritance, and packages the non-portable aspects of mapping tables and
instance variables. Anybody who's serious about this can look in
[CMU-CS-C]<HANDERSON.PUBLIC>FLAVORS-KERNEL.TXT. Please address all specific
comments and suggestions to me, and I'll get back to you (probably next year).
∂08-Dec-84 2039 FAHLMAN@CMU-CS-C.ARPA hooks vs. subset (last try)
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Dec 84 20:39:27 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 8 Dec 84 23:39:44-EST
Date: Sat, 8 Dec 1984 23:39 EST
Message-ID: <FAHLMAN.12069947103.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Snyder%hplabs.csnet@CSNET-RELAY.ARPA
Cc: cl-object-oriented-programming@SU-AI.ARPA
Subject: hooks vs. subset (last try)
In-reply-to: Msg of 7 Dec 1984 13:19-EST from Snyder%hplabs.csnet at csnet-relay.arpa
If someone could come up with a comprehensive proposal for
object-oriented programming in Common Lisp that everyone likes well
enough to adopt, that would be great. We've got a lot of smart people
in this subgroup, most of whom have a lot of experience in
object-oriented hackery, and it is possible that such a high-level
object-oriented could emerge from our discussions. So it's probably
worth kicking around some ideas at this level, and seeing if there's any
common ground. It may be that we're all closer together than we think.
Then again, there are tradeoffs to be made in any object-oriented
system: efficiency vs. late binding vs. ease of implemenation vs.
presenting the user with an elegant and understandable model. It may be
that we have irreconcilable differences in how these tradeoffs should be
made. Perhaps there is a set of tradeoffs out there that we could all
accept, perhaps not. My own view, admittedly based on rather limited
experience, is that flavors goes overboard on the first two of these
issues, and that elegance is butchered for very modest gains in
efficiency. I would hate to see flavors, in its current form, become
the official standard for Common Lisp or even a de facto standard
because it is the only object-oriented system available in most
implementations.
So, while I think that we should discuss what a standard object-oriented
system for Common Lisp might be like, and that we should move toward
such a standard if possible, I think that this is a long shot. We had
better hedge our bets by trying to come up with hooks that will support
a variety of object-oriented systems.
So much for my own view. I should add that the second most-frequent
question (*) that people ask me about Common Lisp is what our plans are
for supporting flavors -- not object-oriented programming, but Flavors
by name. There seem to be a lot of current and soon-to-be Zetalisp
users out there, and they see the lack of flavors as the principal
difficulty in moving between Symbolics, LMI, and (someday) TI systems
and other Common Lisp implementations.
-- Scott
* In case you are wondering, the MOST frequently asked question about
the status of Common Lisp is when there will be an implementation for
Vax/Unix. Don't ask me, ask DEC.
∂11-Dec-84 1955 BYLANDER@RUTGERS.ARPA Re: hooks vs. subset (last try)
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 11 Dec 84 19:54:47 PST
Date: 11 Dec 84 22:54:32 EST
From: Tom Bylander at Ohio State <BYLANDER@RUTGERS.ARPA>
Subject: Re: hooks vs. subset (last try)
To: Snyder%hplabs.csnet@CSNET-RELAY.ARPA
cc: cl-object-oriented-programming@SU-AI.ARPA
In-Reply-To: Message from "Snyder%hplabs.csnet@csnet-relay.arpa" of 7 Dec 84 13:19:18 EST
It seems to me that there is a goal conflict corresponding to the
type of programming that people want to use an object-oriented
language/environment for.
1) System programming. As I understand it, a major use of Flavors is
for programming of essential data types, e.g., the window system.
Such a use demands efficiency (even "modest gains" -- enough modest
gains and sooner or later they all add up to big gains) with perhaps
some cost in understandability, elegance, ease of use, and the like.
2) Research programming. People (like me) use an object-oriented
system to gain leverage on understanding a system which represents and
perhaps eventually solves difficult problems. This use demands
understandability, etc. since it is hard enough to thoroughly
understand the problem without the programming system getting in the
way. This becomes especially important when more than one person is
involved in coding.
3) No programming. Many people already have large, complex programs
in current object-oriented languages.
Example: When active values were discussed, I was amazed to hear
someone say that Flavors had active values. Just access the variables
indirectly by message passing instead of directly by name. From an
elegance viewpoint this is awful. Besides being able to accidently or
malevolently bypass any intended active values, this means that in
general, the two ways of accessing a variable can have completely
different semantics. From an efficiency viewpoint, this may be viewed
as a necessary evil because the addition of true active values would
slow down access, and involve very hairy programming in order to gain
reasonable speed. From the no programming viewpoint, some currently
built programs probably depend on this "feature", and would have to
completely overhauled.
Can one object-oriented language satisfy both system and research
programmers? (satisfying all three views is an overconstrained
problem)
Rather than starting with a already complex system like Flavors,
Loops, or some other comprehensive proposal, I suggest that we start
from scratch, and attempt to build a consensus one piece at a time.
Any comprehensive proposal will have too many implicit assumptions and
too many features to make for a reasonable discussion. We need to
start with something simple so that the efficiency vs. elegance issue
can be tractably approached. I like the suggestion of starting with
something similar to Smalltalk, and when (and if) we agree on the
basics, we can move ahead to other issues.
Tom
-------
∂13-Dec-84 1455 hpatlS!post%hplabs.csnet@csnet-relay.arpa de facto standards
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 13 Dec 84 14:54:57 PST
Received: from hplabs by csnet-relay.csnet id af11777; 13 Dec 84 17:34 EST
Received: by HP-VENUS id AA14200; Thu, 13 Dec 84 10:55:19 pst
Message-Id: <8412131855.AA14200@HP-VENUS>
Date: 13-Dec-84 10:51:49
To: fahlman@cmu-cs-c.ARPA
Cc: cl-object-oriented-programming@su-ai.ARPA
Subject: de facto standards
From: Snyder%hplabs.csnet@csnet-relay.arpa
Source-Info: From (or Sender) name not authenticated.
Scott,
I agree with you that Flavors has significant technical shortcomings, and that
it would be unfortunate if Flavors should become a de facto standard in its
present form.
However, if the demand for Flavors is as great as your message suggests, then
I fear it will be difficult to prevent Flavors from becoming a de facto
standard, despite its technical problems. It should be clear from history
that technical merit plays a relatively minor role in the adoption of language
standards. Fortran, for example, prospered even though its creator disowned
it and worked actively to promote an alternative.
To prevent Flavors from becoming a de facto standard, there must be an
alternative. Simply extending Common Lisp to support alternative objects
systems (the "hooks" approach) does not by itself provide an alternative, but
merely makes it possible for an alternative to arise.
An informal process of developing and evaluating alternative objects systems
is unlikely to produce a viable alternative to Flavors in time. While this
development and evaluation is taking place, usage of Flavors will continue to
increase. By the time an alternative objects system could arise and gather
enough support from the Common Lisp community to be declared the "winner", it
seems quite likely that Flavors will be too well entrenched to dislodge.
Although it would be nice if there were indeed a "free marketplace of ideas"
where alternative objects systems could compete on their technical merits,
there are factors other than technical merit at work in the marketplace.
As I said before, manufacturers will not want to support multiple objects
systems. If Flavors becomes a de facto standard, then other objects systems
will not achieve universal support, even if a set of hooks has been
standardized. Also, if the "portable implementation" of Flavors using hooks
turns out to be inadequate (e.g., not efficient enough), then manufacturers
will be forced by market demand to provide customized implementations of
Flavors; they may well perceive this task to be more important than supporting
the standard hooks.
The best way to avoid the adoption of an inferior standard is for this
committee to develop and endorse a superior alternative. Obviously, it is
very valuable (if not essential) for this alternative to be endorsed by the
Flavors people as well. Such endorsement does not guarantee success, however
(witness Fortran).
Alan
-------
∂13-Dec-84 1736 STICKLEN@RUTGERS.ARPA Clarificaiton Needed
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 13 Dec 84 17:36:19 PST
Date: 13 Dec 84 20:37:29 EST
From: Jon Sticklen <STICKLEN@RUTGERS.ARPA>
Subject: Clarificaiton Needed
To: cl-object-oriented-programming@SU-AI.ARPA
Because of several recent messages in this forum, I feel that some
clarrification is needed. Alan Synder's message and Scott Fahlman's
that preceded it both seem to indicate that there is a large demand
for FLAVORS in the world, hence it may be unavoidable that the CL
standard simply mirror what currently is FLAVORS. [Fahlman's
note argues against it, but Synder's note is what the
following is really aimed at.]
As the message from Tom Bylander tried to say, it is important that
the use of FLAVORS be factored into at least
a) FLAVORS used for internal system work in the ZETA LISP
environment and
b) FLAVORS used for exploratory AI system building.
If it is seriously considered that this body accept FLAVORS as THE
CL object oriented programming standard, then I think it very important
that there be some documentation to support the notion that demand for
FLAVORS is overwhelming for use (b) above. Use (a) seems to me to be
important only for those in the ZETA LISP environment. [Of course, if
it is being suggested that the CL object oriented programming standard
should be made to support the ZETA LISP world, that would be another
matter. But if that is the reason, then it should be made clear.]
The reason I raise this issue is that I'm not sure personally that there
in fact is overwhelming demand for FLAVORS for use (b). At the Austin AAAI,
for example, I visited the KNOBS (sp?) demo at the SYMBOLICS booth. There
I found that KNOBS was build in a local version of FRL, not FLAVORS as I
expected. Further, on visiting a demo of a chemical plant designing system
(whose name I don't remember) at the LMI booth, again I found that the system
was not build in FLAVORS (by that time I expected it). There were other
similar examples.
My question then (based on just what I saw at AAAI): could it be that the
demand for FLAVORS is based on use (a) almost totally, and that use (b)
is in fact rather small? If the answer to that question is "Yes", then
the even deeper question (the one I asked myself) is "Why is that true?".
---jon---
-------
∂15-Dec-84 1128 HANDERSON@CMU-CS-C.ARPA Standardization (ugh)
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 Dec 84 11:27:57 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Sat 15 Dec 84 14:28:34-EST
Date: Sat, 15 Dec 1984 14:28 EST
Message-ID: <HANDERSON.12071681777.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To: cl-object-oriented-programming@SU-AI.ARPA
Subject: Standardization (ugh)
In-reply-to: Msg of 13 Dec 1984 20:37-EST from Jon Sticklen <STICKLEN at RUTGERS.ARPA>
Basically, I think people are going overboard with regard to standardization.
There are only two good reasons to standardize: so that people on different
machines can run the same code (as fast as reasonably possible on a given
architecture), and so that you don't waste space with 100 functions or programs
that all do the same thing. I think that the first is the only thing we really
have to worry about; the more complicated the thing, the fewer people are going
to invent their own way of doing it. If the number of object systems does get
to be a problem, THEN we should sit down and standardize on one, NOT BEFORE
[there will probably only be about two or three major systems in use].
Hey, why don't we standardize on silicon as the material that CL machines
should be made with? It's certainly used a lot...
On the flip side, a REAL programming system makes it easy for you to do REAL
THINGS. One such thing is writing your own object system if you need to,
rather than trying to force your neat abstraction into some inappropriate
scheme. There's always the chance that a programmer will do something silly,
but all you can do is give him the best tools and examples you can and hope he
learns. An object kernel (such as mine) satisfies reason 1 for standardization
(machine compatibility) without prematurely standardizing.
Of course, there can (and should be) a "standard Flavors" that programs can
use, so that if an implementation has the hooks (and, for worst case, I believe
the hooks can be implemented entirely in CL), then you just see that Flavors is
loaded (which sees that the hooks are?), and your program works fine.
De facto standards are different from standards frozen into the language; at
best, losing standards are ignored - at worst, they are used. I partially feel
that programs written with losing tools probably deserve to lose, although if
nothing better is available, I suppose the authors have no choice. I intend to
give them a choice.
What I've put into the kernel is all the basic stuff that I think a GOOD object
system will have in common with Flavors. The difference is mainly in how types
are "mixed" - I have no idea what the "correct" way of doing this is, but I'd
sure like to see it. Again, my current proposal for the kernel is in
[cmu-cs-c]<handerson.public>flavors-kernel.txt
Maybe this should start being considered as a proposal for a standard.
∂15-Dec-84 1923 FAHLMAN@CMU-CS-C.ARPA Standardization (ugh)
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 Dec 84 19:23:16 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 15 Dec 84 22:23:50-EST
Date: Sat, 15 Dec 1984 22:23 EST
Message-ID: <FAHLMAN.12071768294.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: cl-object-oriented-programming@SU-AI.ARPA
Subject: Standardization (ugh)
In-reply-to: Msg of 15 Dec 1984 14:28-EST from Steven <Handerson>
I think Handerson misses the most important reasons for standardization:
stability and sharing of code across the largest possible community. I
want to learn *ONE* object-oriented system to the point where I can use
it well, write a lot of code in it, and I want that system to be the one
that all my friends use so that I can borrow their code and they can
borrow mine. I want this one system to be efficient enough for systems
programming (though that DOES NOT mean that I'm willing to sacrifice a
lot of elegance for that last 10%) and I want it to be clean enough so
that I don't get mad every time I use it. I don't want to invest a lot
of effort in a system whose users don't really like it; such a system is
likely to go away as soon as something good comes along.
I think the optimal plan for this group is the following:
(1) Define a minimal set of low-level hooks that can support a
variety of object-oriented systems.
(2) Implement a portable Flavor system -- there's a demand for this,
even if we eventually move to something else as a standard. However, we
should try not to let Flavors creep into other essential parts of the
system.
(3) Try to come up with a system that we all like better than Flavors.
This group is the right set of people to work on that, and the longer we
wait, the harder it will be to get people to switch.
(4) Implement this new system in a protable way so that we can play with
it and refine it.
(5) Maybe someday, if the new system becomes popular, accept it as a
white-pages standard.
-- Scott
∂18-Dec-84 1537 KMP@MIT-MC protocols/syntax, semantics of SEND, genericity
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Dec 84 15:37:05 PST
Date: 18 December 1984 18:19-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject: protocols/syntax, semantics of SEND, genericity
To: CL-Object-Oriented-Programming @ SU-AI
I just got caught up on my reading of these object discussions.
I have the following immediate comments on a variety of topics
that have been discussed.
* Protocols
I strongly agree with the suggestion made earlier that even if a particular
message passing style (LOOPS vs FLAVORS vs ...) is not standardized upon,
that at least a syntax should be standardized upon so that users of
object systems are not burdened with knowing how those systems were
implemented. Some of my other comments will come back to this issue.
* Syntax: SEND should be internal
Yale Scheme (aka T) has message passing without using the SEND syntax.
Instead, message sending uses the same syntax as function calling. eg,
(SEND window :X-POS) could be written (WINDOW-X-POS window)
(SEND window :SET-X-POS 3) could be written (SETF (WINDOW-X-POS window) 3)
This is more abstract since the user can't tell from the call how window
is implemented.
This is more flexible since standard utilities like ARGLIST and SETF
are naturally appropriate without the addition of special mechanism.
As an accidental (but fortunate) consequence, people are discouraged from
"recycling" message names. Lots of objects might want to handle a FOO
message, but they should all agree that the same abstract operation is
being performed. It is common to see LispM programmers recycle names for
different meanings, and later incidences of (SEND X :FOO) may be confusing
if you don't know the type of X. In the functional situation, people are
not as inclined to do this (partially because the compiler does number of
argument checking, partially because the debugging info associated with
ARGLIST would get clobbered), so if you see (FOO X), you have a better
idea what is going on even if you don't know what X is.
* SEND = FUNCALL ?
I believe it to have been a real mistake that (FUNCALL instance . args)
is the same as (SEND instance . args) on the LispM. I would like to see
instances in general not be funcallable.
The fact that these two are confused means you can't define message
handlers for other lisp objects (particularly functions, since
(SEND #'CAR ':NAME) is otherwise ambiguous with (FUNCALL #'CAR ':NAME),
which would be an error).
* (SEND non-instance ...)
I would like to see non-instances be able to handle messages.
I am not so fussy about whether those messages are extensible; I just
don't want sending a message to the thing to be an error.
Mostly I would be happy if they answered only primitive operations like
OPERATION-HANDLED-P, DESCRIBE, and so on.
* (primitive instance)
I don't see any reason to make CAR send a CAR message unless we want to
go the route of changing CL to a pure message-passing language, which
seems a bit intense.
Also, there are severe efficiency issues.
But in any case, someone can always write a MESSAGE-PASSING package
where MP:CAR called LISP:CAR on primitive lists and otherwise sent a
message. Anyone that wanted message-passing CAR could shadow CAR with
MP:CAR, etc. and get the effect at no cost to code that didn't want it.
The same applies to MP:+, etc.
∂18-Dec-84 1542 KMP@MIT-MC Keywords as messages
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Dec 84 15:42:06 PST
Date: 18 December 1984 18:33-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject: Keywords as messages
To: CL-Object-Oriented-Programming @ SU-AI
Thus far, no one has suggested that message keys be keywords. In fact,
people have been using packaged message names, which pleases me.
I wish to explicitly suggest that we encourage that message keys not be
keywords (ie, symbols on the keyword package).
If you agree with me that message sends should be syntactically
indistinguishable from function calls, then it should be obvious that
keywords would be a bad idea for messages, since I imagine people
wouldn't be happy with notation like (:CLEAR-SCREEN w).
Another reason, though, is that you cannot know at the time you make an
abstract type what whether it will ever parent other types and whether
such parentage will result in name collisions. Name collisions should
occur only when the two names are methods implementing the same protocol
(in which case, generally, both methods are doing roughly the same thing
and it matters a lot less that one of the methods is shadowed).
Keywords have no potential for scoping, so if code on two modules want
to produce flavors which handle messages named FOO, they can't both call
them :FOO without colliding for fear someone will mix the two flavors
and be able to access only one of the two methods. I recommend that we
actively encourage that they be called JOE:FOO, BILL:FOO, etc.
In general, keywords should not be used in any context where the
space of identifiers is not fixed and non-extensible.
Current custom in LispM and NIL flavors is to use keywords as
message names. In some cases (particularly with generated message
names for reading/setting variables), the semantics of the provided
primitives is such that using non-keywords is likely to lead to
trouble. This is a problem that should be cleaned up before any
flavors package is adopted for CL distribution.
-kmp
∂18-Dec-84 2103 @MIT-MC:Henry%MIT-OZ@SCRC-STONY-BROOK Messages as objects
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Dec 84 21:03:22 PST
Received: from MIT-APIARY-5 by MIT-OZ via Chaosnet; 18 Dec 84 23:48-EST
Date: Tue, 18 Dec 84 23:48 EST
From: Henry Lieberman <Henry%MIT-OZ@SCRC-STONY-BROOK.ARPA>
Subject: Messages as objects
To: Kent M Pitman <KMP@MIT-MC.ARPA>
Cc: CL-Object-Oriented-Programming@SU-AI.ARPA
In-reply-to: The message of 18 Dec 84 18:33-EST from Kent M Pitman <KMP at MIT-MC>
This may be too radical for some of you guys, but I would like to suggest
that messages should be objects [and not just symbols]!
So far, none of the Lisp-embedded object systems permit this, although fully
object-oriented systems like Smalltalk and Actors do. But it is worth thinking
about making sure this can eventually be done. Here are some reasons
why [I've got more if anyone wants to discuss it]:
- Implementing "local messages", as Kent suggests, is possible this way,
without relying on packages, keywords, etc.
- Inheritance can be used for messages, just like objects. The user might
want a message that's "just like the print message, except ..." which clearly
calls for inheritance. This makes a nice duality between messages and
objects which receive messages.
- Sometimes, the user would like to implement one handler to handle a
group of related message "keywords", without having to define a separate method
for each keyword. Example: An object might want to say, "Send all messages
having to do with graphics to the graphics-manager object" where these might
include :DRAW, :ERASE, etc. One would also like to avoid burning in a specific
list of these, possibly having a procedural test as to whether a message was
a graphics message or not.
- Implementing "default behavior" for messages. Often, the behavior of
object systems is extended by introducing new messages to which every object
should have a response. Examples are :PRINT [everything should print],
:EQUAL [everything should say whether it is equal to something else].
Traditionally, these are done by defining methods on the root of the
inheritance hierarchy [OBJECT in Smalltalk/Loops, VANILLA-FLAVOR in Flavors].
The problem is that as these proliferate, the root becomes a bottleneck,
accumulating large numbers of methods. The obvious solution if messages
are themselves objects is to give each message object a :DEFAULT method
which can be used to respond if the object does not have an idiosyncratic
response. If an object does not have a :PRINT method, OBJECT turns around and
sends the :PRINT message a :DEFAULT message to print the object.
This is probably the most important practical reason to allow messages
to be objects.
∂19-Dec-84 1700 HANDERSON@CMU-CS-C.ARPA Fahlman's mail, syntax and T operations, standard send
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Dec 84 17:00:02 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Wed 19 Dec 84 19:38:43-EST
Date: Wed, 19 Dec 1984 19:37 EST
Message-ID: <HANDERSON.12072786625.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To: CL-Object-Oriented-Programming@SU-AI.ARPA
Subject: Fahlman's mail, syntax and T operations, standard send
In-reply-to: Msg of 18 Dec 1984 18:19-EST from Kent M Pitman <KMP at MIT-MC>
In response to Fahlman, I feel that most object systems will represent a
small body of code (Flavors sans kernel should be one small to midsize file)
that any CL can run (with the benefit of a kernel), and that there will
typically be only three or four major ones at the most. Xerox could support
LOOPS, Symbolics would support Flavors, etc. It shouldn't be hard and
shouldn't cost anything to the users.
In response to KMP's mail:
What do you mean about syntax? There are a number of ways that the
semantics can change and force the syntax to change - changing the number or
kind of parameters to something, for example. I've suggested a common
syntax for sends - (send object message-name . message-arguments) - but all
I had to assume (phew) was that all messages have a unique identifying
(atomic) name (like a function name) and some arguments. I'm not sure how
much you want to assume about how inheritance is done, since if we have
original Flavors AND something else, I would DEMAND that inheritance be done
differently. Flavors is a complete and utter kludge. Doing things the same
so that everybody can understand them would have left us in the Dark Ages.
Operations (defined with DEFOPERATION, even in T) can be macros that expand
into a send of the operation name. An optional send function can be
supplied (to DEFOPERATION) instead of lisp:send, so you can make use of any
macroexpansions or defsubsts of the more specific sending function.
The only problem with the scheme that I've been proposing for a "standard
send" is that it may cost a function call in order to support the various
sending functions. Still, there could be some way of representing one or more
"standard" sending functions so that no extra function call is made - indeed,
if lisp:send is an instruction, that instruction performs the standard send.
Thus the "standard" thing can be done fast without ruling out the
alternatives. [See next message.]
∂19-Dec-84 1746 HANDERSON@CMU-CS-C.ARPA CAR sending a message, Liebermann's message
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Dec 84 17:46:32 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Wed 19 Dec 84 20:47:09-EST
Date: Wed, 19 Dec 1984 20:47 EST
Message-ID: <HANDERSON.12072799274.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To: CL-Object-Oriented-Programming@SU-AI.ARPA
Subject: CAR sending a message, Liebermann's message
KMP: The compiler probably replaces calls to CAR with instructions, so you
want to catch the operation before it errors (at "bugout" time for
microprogrammed machines, but what about standard architectures?). Anyway,
I think all this stuff will have to be implementation-dependent, unless
anybody can show it has some use. I don't really see much use for sending
to primitive types, but I've proposed a way to handle it.
Henry: The model I'm operating under is that sending a message is like a
function call, but the function that gets called depends on the type of the
receiver. It's simple and pretty common. Anything else probably takes
longer and is probably different enough to warrant a totally different
mechanism if it's useful (like production systems).
A basic idea in Flavors is that it constructs and compiles a function that
calls the methods in some sequence, so the only speed issues are function
calls and the time it takes to recompute the "combined method" when
something changes. Yeah, if you add something to Vanilla-flavor it has to
be added to EVERYTHING, which may take a while.
"Just like the print message, except..." usually calls for intelligence;
generalized inheritance does not exist. Flavors doesn't go far enough in
trying to get around this- you can't even define new ways of combining
methods (and new method types). I hope this group is open enough to change
that somebody can do it right sometime; mixing could be made much more
complex with no change in runtime speed.
∂20-Dec-84 1239 JAR@MIT-MC Messages as objects
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 20 Dec 84 12:39:00 PST
Date: 20 December 1984 15:22-EST
From: Jonathan A Rees <JAR @ MIT-MC>
Subject: Messages as objects
To: Henry @ MIT-OZ
cc: CL-Object-Oriented-Programming @ SU-AI
In-reply-to: Msg of Tue 18 Dec 84 23:48 EST from Henry Lieberman <Henry%MIT-OZ at SCRC-STONY-BROOK.ARPA>
Date: Tue, 18 Dec 84 23:48 EST
From: Henry Lieberman <Henry%MIT-OZ at SCRC-STONY-BROOK.ARPA>
This may be too radical for some of you guys, but I would like to suggest
that messages should be objects [and not just symbols]!
So far, none of the Lisp-embedded object systems permit this, although fully
object-oriented systems like Smalltalk and Actors do.
None? T's object system does exactly what you suggest, with many of the
benefits you point out (e.g. defaults are handled pretty much as you
say). Messages (a.k.a. "keys" or "operations") are objects which can
themselves answer messages. There is a form which evaluates to an
anonymous message, much in the same way that a LAMBDA form evaluates to
an anonymous functions. The usual convention is to assign them to
global variables (functions), but that's not necessary.
Jonathan
∂20-Dec-84 1647 Kahn.pa@Xerox.ARPA What are we up to?
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 20 Dec 84 16:47:04 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 20 DEC 84 16:47:52 PST
Date: 20 Dec 84 16:52 PST
From: Kahn.pa@XEROX.ARPA
Subject: What are we up to?
To: CL-Object-Oriented-Programming@SU-AI.ARPA
As many have said, we can do either specify what hooks Common Lisp
should have to implement object systems, try to find a consensus on a
object sub-language, or both. My feeling is that it would be great if
we could come to some consensus and define a better language. I am
pretty pesimistic however. As we have seen recently people have rather
different ideas about pretty basic things. I don't see a consensus on
(1) instance variables
-- special syntax vs. ordinary symbols
-- semantics, when are defaults (if ever) copied down, active values,
access of IVs of other than self,...
(2) method combination
Flavors is a both a language for describing methods and a language
for describing method combination. I think most people that dislike
Flavors dislike the method combination language. Handerson has proposed
generalizing method combination but will that make things better.
SmallTalk has a notion of sending a message on along to the super of the
class in which the calling method is defined. Loops generalizes this
for multiple supers. This clearly is very general and is easier to use
and can be as efficient. What do people think?
(3) Name spaces
-- should selectors share a name space with Lisp functions?
-- should selectors be in the keyword package?
and so on.
I think we can try a little longer and see if there is some consensus on
some of these issues. If there is then maybe we really can design some
language that improves upon Flavors, Loops, and SmallTalk. If there
isn't then we should go back to the question of what hooks do we want.
Btw. Objects in T is new to me. Does someone have pointers to
references?
∂21-Dec-84 1206 @MIT-MC:HENRY@MIT-OZ Messages as objects
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 Dec 84 12:06:32 PST
Date: Fri, 21 Dec 1984 15:06 EST
Message-ID: <HENRY.12073261556.BABYL@MIT-OZ>
From: HENRY%MIT-OZ@MIT-MC.ARPA
To: Jonathan A Rees <JAR@MIT-MC>
Cc: CL-Object-Oriented-Programming@SU-AI.ARPA
Subject: Messages as objects
In-reply-to: Msg of 20 Dec 1984 15:22-EST from Jonathan A Rees <JAR at MIT-MC>
∂21-Dec-84 2019 @MIT-MC:Henry%MIT-OZ@SCRC-STONY-BROOK Messages as objects
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 Dec 84 20:19:46 PST
Received: from MIT-APIARY-9 by MIT-OZ via Chaosnet; 21 Dec 84 23:19-EST
Date: Fri, 21 Dec 84 23:20 EST
From: Henry Lieberman <Henry%MIT-OZ@SCRC-STONY-BROOK.ARPA>
Subject: Messages as objects
To: Jonathan A Rees <JAR@MIT-MC.ARPA>
Cc: Cl-Object-Oriented-programming@SU-AI.ARPA
In-reply-to: The message of 20 Dec 84 15:22-EST from Jonathan A Rees <JAR at MIT-MC>
Thank you, I stand corrected. T's approach on this issue seems much better
than the other Lisp-embedded object langauges.
∂22-Dec-84 0054 @MIT-MC:Henry%MIT-OZ@SCRC-STONY-BROOK What are we up to?
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Dec 84 00:53:58 PST
Received: from MIT-APIARY-9 by MIT-OZ via Chaosnet; 21 Dec 84 23:45-EST
Date: Fri, 21 Dec 84 23:46 EST
From: Henry Lieberman <Henry%MIT-OZ@SCRC-STONY-BROOK.ARPA>
Subject: What are we up to?
To: Kahn.pa@XEROX.ARPA
Cc: CL-Object-Oriented-Programming@SU-AI.ARPA
In-reply-to: The message of 20 Dec 84 19:52-EST from Kahn.pa@XEROX.ARPA
(1) instance variables
-- special syntax vs. ordinary symbols
-- semantics, when are defaults (if ever) copied down, active values,
access of IVs of other than self,...
I propose that the standard require that a method access its instance variables
using messages. The most important reason for this is that
using messages hides the implementation details -- a compiler could optimize
it using variable access, but maybe another implementation could do it differently.
Since deciding whether a property of an object is implemented by an
instance-variable or a method is often a time-space tradeoff, it's very helpful
to be able to change that decision without changing all the callers.
I use a macro (MY :VARIABLE) => (SEND SELF :VARIABLE), which looks nice, as in
(DEFOBJECT TURTLE (X Y PEN))
(DEFMETHOD (TURTLE :MOVE-TO) (NEW-X NEW-Y)
(DRAW-LINE (MY :X) (MY :Y) NEW-X NEW-Y (MY :PEN)))
(2) method combination
Flavors is a both a language for describing methods and a language
for describing method combination. I think most people that dislike
Flavors dislike the method combination language. Handerson has proposed
generalizing method combination but will that make things better.
SmallTalk has a notion of sending a message on along to the super of the
class in which the calling method is defined. Loops generalizes this
for multiple supers. This clearly is very general and is easier to use
and can be as efficient. What do people think?
I agree wholeheartedly that one of the major problems with Flavors is method
combination, and strongly urge that the standard not require method combination.
Multiple supers is much better, and should be provided for.
I think the standard should also require a mechanism called delegation, the
idea of one object forwarding a message to another object to reply in its stead.
This is subtly different from ordinary message sending, but allows you to
combine objects in place of combining methods.
I'll wait for discussion of inheritance mechanisms to explain the details
of delegation, which is discussed in some of the actor literature,
but I believe that delegation [along with multiple supers]
replace all plausible uses for method combination.
∂22-Dec-84 1152 FAHLMAN@CMU-CS-C.ARPA What are we up to?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 22 Dec 84 11:52:18 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 22 Dec 84 14:22:51-EST
Date: Sat, 22 Dec 1984 11:41 EST
Message-ID: <FAHLMAN.12073486289.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Henry Lieberman <Henry%MIT-OZ@MIT-MC.ARPA>
Cc: CL-Object-Oriented-Programming@SU-AI.ARPA
Subject: What are we up to?
In-reply-to: Msg of 21 Dec 1984 23:46-EST from Henry Lieberman <Henry%MIT-OZ at SCRC-STONY-BROOK.ARPA>
Henry,
Could you expand a bit on how, and under what conditions, this use of
messages to access variables can be made efficient by the compiler?
Would we have to require that the decision about whether the slot is a
variable or method be frozen before anything referencing these slots is
compiled? If so, the flexibility you speak of seems a bit marginal. I
can't imagine that this idea will sell (at least for tense applications)
if it makes the inefficient form of access a near-universal default, so
getting the compiler to smash most of the cases most of the time would
seem to be crucial.
There certainly seems to be a lot of flexibility here if the efficiency
problem is not too bad. Would this sort of thing provide "active
values" in all of the senses that people care about? Looks to me like
it would, but I may be missing something.
If (MY :VARIABLE) turns into (SEND SELF :VARIABLE), what would SETF of
(MY :VARIABLE) turn into? And do we really want these varaible names to
be keywords?
I personally have no strong opinion about whether access to instance
variables has to look like access to regular variables or whether there
can be some special syntax for it. I mildly favor a special syntax, but
since my experience as a user of these systems is limited, I can't
really be sure that I would not find this to be a drag in the long run.
A special syntax would allow all sorts of things to be done with many
fewer hooks into the rest of the language, and would probably make it
much easier for mildly different object-oriented systems to co-exist.
On the other hand, I can see where people who are used to referencing
instance variables just like all other variables would view a special
syntax for this as a great leap backward, and one which they are
unwilling to take.
Perhaps if references to instance variables are only allowed within
certain lexical contexts (the bodies of certain macros and special
forms), and if the instance variables are known at the time of entry to
these forms, then the only hook we need is a "symbol macro" construct
that substitutes an arbitrary form for a symbol when it is seen within
some lexical form. Thus, within a defmethod for the flavor BAR we can
turn any reference to instance variable FOO into (MY FOO) or whatever.
Given that single hook, we could allow some systems to use special
syntax while others continue to use (or appear to use) variable-like
sytnax. (This is an idea that Steve Handerson has been pushing.) Of
course there still remains the problem of what the surface-level default
should be for an object-oriented system that we can all love.
-- Scott
∂22-Dec-84 1410 HANDERSON@CMU-CS-C.ARPA What are we up to?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 22 Dec 84 14:10:14 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Sat 22 Dec 84 17:10:21-EST
Date: Sat, 22 Dec 1984 17:10 EST
Message-ID: <HANDERSON.12073546233.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To: Henry Lieberman <Henry%MIT-OZ@SCRC-STONY-BROOK.ARPA>
Cc: CL-Object-Oriented-Programming@SU-AI.ARPA
Subject: What are we up to?
In-reply-to: Msg of 21 Dec 1984 23:46-EST from Henry Lieberman <Henry%MIT-OZ at SCRC-STONY-BROOK.ARPA>
There seems to be a general lack of attention to the tradeoffs of various
systems. It sounds like T- or LOOPS- like things that do things at runtime are
generally slower than things like Flavors, since Flavors tries to do all it can
at compile time. Also, instance variable references in Flavors are an
indirection through a mapping table; probably faster than a hashtable
reference. Hence Flavors is preferable for low-level system programming and
apparently for all manner of hackish things, whereas higher-level programmers
probably need LOOPS or something to maintain their sanity. Then again it's
possible that the overhead is deemed negligible, and we might as well do stuff
at runtime. I'm not sure.
Also, the syntax of Flavors (etc.) reflects the semantics. Since we don't want
to often change what are and aren't instance variables (so that we CAN do
things at compile time), the instance variables are made to look like normal
variables. It's also been decided it would be neat if they acted like lexical
variables, and can be closed over.
I think it's obvious that there should be at least two major object systems;
one that does stuff at runtime (and is therefore more flexible) and another
that does stuff at compile time (and is therefore more efficient).
Furthermore, I think making an object system is more of an art than a science,
for the same reason that mathematics is; they're intellectual tools. I
wouldn't want to force someone to use my tools, but I don't think I should be
forced to use Flavors all the time either. I propose that we have a kernel
that supports diverse object systems, but that we continue trying to develop a
good standard (set of) systems.
RUNTIME OBJECT SYSTEM
The ability to trade off instance-variable vs. message should be user-visible,
not part of the compiler or object system. Active values can use this. You
can do this by remembering method code and recompiling anything referring to
that instance variable, but I'd rather there be a primitive that did it, even
if it cost some time. This would allow methods to close over lexical variables
without making the closure-handling code worse, besides improving user response
time.
KERNELS
My kernel could be expanded to support runtime systems by adding "methods" that
would set and get an instance variable (without having to call a function).
Everything could send a message, and some messages would be (fairly) quickly
converted to instance-variable references, without the need to recompile
anything. This would also speed up accessing instance variables of other
objects.
The object system would have to standardize the names of the messages; I'd
suggest just the iv name and the iv name prepended with SET-, interned in the
same package.
METHOD COMBINATION
My current impression is that everything regarding multiple inheritance is a
kludge, and you can't justify one kludge as compared with another except in
terms of efficiency or ease of use. In the first, Flavors wins, and the second
depends upon who you ask. You seem to be ignoring the fact that, although just
as POWERFUL, method-combination is "automatic" - the system, not the
programmer, writes the code. I think it's currently done wrong, but somebody
might figure out some better way.
If we assume the best, when we combine types an artificially intelligent
machine goes and figures out what order etc. to call the methods in. This may
take a while, and is best done at compile-time. If you don't like that, how
about something that asks the programmer how to solve conflicts? You want to
do that at runtime?
ENDING PLEA
Would someone please give me a reference (net address, anything) to find out
more about T's object system? A manual would be nice.
∂22-Dec-84 1653 Bobrow.pa@Xerox.ARPA Instance Variable Access
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 22 Dec 84 16:53:07 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 22 DEC 84 16:53:57 PST
Date: 22 Dec 84 16:58 PST
From: Bobrow.pa@XEROX.ARPA
Subject: Instance Variable Access
To: CL-Object-Oriented-Programming@SU-AI.ARPA
cc: Kahn.pa@XEROX.ARPA, Bobrow.pa@XEROX.ARPA
(1) instance variables
-- special syntax vs. ordinary symbols
-- semantics, when are defaults (if ever) copied down, active
values,
access of IVs of other than self,...
It is clear to me if we are going to be able to allow different
experiments with how instance variables are implemented, then it is good
to make some syntactic distinction in their access form. Even Henry,
who uniformly prefers message call, uses a macro to hide that;clearly
(SEND self V1) looks uglier than (MY: V1).
Symbol macros automatically generated from lexical scope do the same
thing, but I think lose when trying to read the code. But surely that
can be another level of user option.
In terms of implementation, how an access is compiled (interpreted)
might be left to the class of the method. A computed macro for (MY: V1)
could simply do (SEND: (Class self) CompileGet 'V1), and
(SEND: (Class self) CompilePut 'V1 valueExpression)
for the (SETF (MY: V1) valueExpression). This allows not only
arbitrary experimentation between systems, but even mixing within a
single system. It would even allow for optimization by inclusion of a
mixin class for the class, etc.
One thing that is implicit in this description is that the class of an
object better be an object as well, prepared to receive at least
CompilePut, ... messages. This is not now true for classes in some of
the systems being discussed. Is this important?
∂23-Dec-84 1517 @MIT-MC:Henry%MIT-OZ@SCRC-STONY-BROOK What are we up to?
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 23 Dec 84 15:17:15 PST
Received: from MIT-APIARY-4 by MIT-OZ via Chaosnet; 23 Dec 84 18:17-EST
Date: Sun, 23 Dec 84 18:15 EST
From: Henry Lieberman <Henry%MIT-OZ@SCRC-STONY-BROOK.ARPA>
Subject: What are we up to?
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Cc: CL-Object-Oriented-Programming@SU-AI.ARPA
In-reply-to: <FAHLMAN.12073486289.BABYL@CMU-CS-C.ARPA>
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Could you expand a bit on how, and under what conditions, this use of
messages to access variables can be made efficient by the compiler?
Would we have to require that the decision about whether the slot is a
variable or method be frozen before anything referencing these slots is
compiled?
No, of course not. The idea is that at compile time, a reference
(MY :VARIABLE) is compiled to a direct variable access, providing that
the class whose method this is in has a variable named :VARIABLE and
no other method named :VARIABLE. Otherwise it compiles (SEND SELF :VARIABLE).
It is possible that after this compilation the user could define a
method with that name, making obsolete that compilation. The defining
forms check for this and force recompilation or revert to interpreted version
for that reference. Flavors must do dynamic recompilation anyway for certain
sorts of definitional changes.
If (MY :VARIABLE) turns into (SEND SELF :VARIABLE), what would SETF of
(MY :VARIABLE) turn into?
In ZetaLisp, (SETF (MY :VARIABLE) NEW-VALUE) does exactly what you would
expect, sets the value of the instance variable to NEW-VALUE.